openclaw - 💡(How to fix) Fix [Bug]: qmd collection add hangs under gateway init, triggers SIGKILL restart loop [1 comments, 2 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

On gateway start, qmd collection add ... --name memory-root-main --mask MEMORY.md can hang past TimeoutStopSec=30, causing systemd to SIGKILL the gateway and enter an auto-restart loop. The same qmd collection add invocation completes in ~5s when run directly via the qmd binary outside the gateway.

Steps to reproduce

1. Have an existing memory-root-main qmd collection (so memory init takes the "recreating managed collection" path).
2. Start the gateway via the user systemd unit, with active-memory and/or memory-core plugins enabled along with the usual provider/channel set.
3. Restart the gateway: systemctl --user restart openclaw-gateway.
4. Observe the gateway reach [gateway] ready, then on the next stop log qmd collection add ... timed out after 30000ms, followed by State 'stop-sigterm' timed out. Killing. and SIGKILL.
5. systemd auto-restarts; loop repeats.

To verify the qmd CLI itself is healthy:

qmd collection add ~/.openclaw/workspace --name memory-root-main --mask MEMORY.md
# completes in ~5s

Expected behavior

The recreate-collection path should complete in single-digit seconds, as it does when the same command is invoked directly via the qmd binary.

Actual behavior

Inside the gateway process the call hangs >30s, triggering TimeoutStopSec=30 and SIGKILL. systemd auto-restarts the unit; the same hang recurs and the cycle continues.

OpenClaw version

2026.4.26 (be8c246)

Operating system

Linux 6.8.0-110-generic

Install method

npm global

Model

anthropic/claude-opus-4-7

Provider / routing chain

openclaw -> anthropic

Additional provider/model setup details

qmd version: 2.0.1 (system binary at /usr/bin/qmd). Plugins loaded at the time of failure: active-memory, anthropic, browser, device-pair, memory-core, phone-control, slack, talk-voice.

Logs, screenshots, and evidence

[memory] qmd collection add conflict for memory-root-main: collection name already exists; recreating managed collection
[memory] qmd collection add failed for memory-root-main: qmd collection add ~/.openclaw/workspace --name memory-root-main --mask MEMORY.md timed out after 30000ms
[gateway] qmd memory startup initialization armed for 1 agent: "main"
[gateway] signal SIGTERM received
[gateway] received SIGTERM; shutting down
systemd: openclaw-gateway.service: State 'stop-sigterm' timed out. Killing.
systemd: openclaw-gateway.service: Killing process N with signal SIGKILL.
systemd: openclaw-gateway.service: Failed with result 'timeout'.

After running qmd collection add ~/.openclaw/workspace --name memory-root-main --mask MEMORY.md outside the gateway, the next gateway restart logs:

[memory] qmd collection add conflict for memory-root-main: collection name already exists; recreating managed collection
[memory] qmd collection add conflict for memory-dir-main: collection name already exists; recreating managed collection
[gateway] qmd memory startup initialization armed for 1 agent: "main"

…and the gateway stays up indefinitely.

Impact and severity

Affected: gateway hosts on 2026.4.26 with active-memory and/or memory-core enabled and a pre-existing memory-root-main qmd collection. Severity: High — gateway in continuous SIGKILL/restart loop; all channels intermittently unreachable. Frequency: every gateway start/restart until manual workaround applied (3+ consecutive cycles observed in a single session). Consequence: agents unreachable across all channels for the duration of the loop (~30s SIGKILL timeout + ~10s restart, repeated).

Additional information

Hypothesis (not verified): lock contention or serialization issue between concurrent plugin inits hitting qmd collection add in parallel — active-memory and memory-core both touch qmd at startup, and the in-gateway invocation hangs while the same command outside the gateway completes in seconds.

Workaround: stop the gateway, run qmd collection add <workspace> --name memory-root-main --mask MEMORY.md directly, then start the gateway. Subsequent recreates inside the gateway then take ~1–2s and the loop does not recur.