openclaw - 💡(How to fix) Fix Background tasks stay 'running' forever after gateway crash/restart, blocking channel reload + saturating CPU [1 comments, 2 participants]

Summary

When the gateway process crashes or is restarted while background task runs (cron, subagent, cli) are in-flight, the task records remain in 'running' status indefinitely. They block channel reload, accumulate across restarts, and eventually saturate the event loop.

Repro

1. Trigger an isolated agentTurn cron with a long timeout (e.g. opus-backed nightly pass)
2. While running, restart the gateway (openclaw gateway restart) or let it crash
3. After restart: openclaw tasks shows the run still in 'running' state — forever

Observed in production

• Gateway PID 2087813, ~3h45min uptime
• 88.7% CPU sustained on 1-core VPS
• 32 task runs stuck 'running' (most for hours)
• Channel reload deferred 11,111,502ms (~3h) with 'still deferred' diagnostic logged every ~30s
• User-facing session 'stuck processing' for 200-328s before model started
• SIGUSR1 hot-reload didn't clear them; only openclaw gateway restart (full process replace) recovered. CPU dropped 88.7% → 5%

Logs (excerpt)

[reload] channel reload still deferred after 11079287ms with 4 operation(s), 1 reply(ies), 2 embedded run(s), 32 task run(s) active
[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu eventLoopDelayP99Ms=5259.7 eventLoopUtilization=1 cpuCoreRatio=0.993
[diagnostic] stuck session: sessionId=... state=processing age=328s queueDepth=1

Expected

On gateway boot: any background task run whose owning process/session is no longer alive should auto-reconcile to 'lost' (or 'interrupted') status. Channel reload should not be blocked indefinitely by stale task slots.

Workaround

Manual openclaw gateway restart (full process replace, not SIGUSR1).

Version

2026.4.27 (cbc2ba0)