openclaw - 💡(How to fix) Fix [Linux/systemd] Gateway 2026.4.5 enters infinite self-fork restart loop on startup [2 comments, 1 participants]

Summary

OpenClaw 2026.4.5 gateway enters an infinite restart loop on Linux/systemd immediately after startup. The gateway forks a child process ~8 seconds after reaching "ready", the child kills the parent via cleanStaleGatewayProcessesSync(), then the child forks again — infinite loop. No CLI invocation or agent session trigger required; it happens on a clean systemctl --user start.

Environment

• OpenClaw: 2026.4.5 (3e72c03)
• OS: Ubuntu 24.04 LTS (Linux 6.x)
• Node: v22.22.1
• RAM: 32GB
• Gateway: systemd user service, loopback bind
• Profile: custom (OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH set)
• Channels: Discord enabled, Slack enabled (socket mode)
• Cron: 2 jobs (disabled during testing — loop persists without them)

Steps to Reproduce

1. Upgrade OpenClaw from 2026.3.x to 2026.4.5 via npm i -g openclaw
2. Start gateway via systemctl --user start openclaw-gateway.service
3. Gateway reaches "ready" in ~2 seconds
4. ~8 seconds later, main process receives SIGKILL (exit code 9)
5. systemd restarts (Restart=always), new process repeats the cycle

Log Pattern (repeats indefinitely)

[gateway] ready (3 plugins, 0.7s)
[gateway] starting channels and sidecars...
[hooks] loaded 4 internal hook handlers
# ~8 seconds pass, 14s CPU time (100%+ utilization)
systemd: Main process exited, code=killed, status=9/KILL
systemd: Scheduled restart job, restart counter is at 213.
[restart] killing 1 stale gateway process(es) before restart: <PREV_PID>

The [restart] log from the child process shows it killing the parent PID. In one instance, the log showed a process killing its own PID.

Root Cause Analysis

The restart mechanism in restart-stale-pids-6v9JnhXs.js uses lsof -nP -iTCP:PORT -sTCP:LISTEN to find PIDs on the gateway port, then sends SIGTERM + SIGKILL. The gateway appears to self-fork a replacement process during startup (after "starting channels and sidecars"), and this child kills the parent. Since systemd sees the main PID die, it restarts the service, creating an infinite loop.

This is distinct from but related to:

• #32348 — gateway restart from agent session causes crash loop
• #52851 — CLI spawns new gateway instance conflicting with systemd service
• #46849 — gateway status spawns nested gateway from inside running service

Those issues are triggered by CLI invocations from within the gateway context. This issue requires no external trigger — the gateway self-forks on its own during startup.

What Does NOT Fix It

1. Migrating cron jobs to new payload: {kind, text} format (fixed separate cron TypeError)
2. Disabling all cron jobs (enabled: false)
3. Updating meta.lastTouchedVersion to 2026.4.5
4. Updating systemd OPENCLAW_SERVICE_VERSION env var
5. Setting commands.restart: false
6. Setting gateway.reload.mode: "off"
7. Disabling Slack channel
8. Adding ExitType=cgroup to systemd unit
9. Changing cron wakeMode to next-heartbeat
10. Reinstalling service via openclaw gateway install --force

Key Observations

• A second gateway instance on the same machine (different profile/port) that was started before the upgrade is stable — it's running the old pre-2026.4.5 binary from memory
• A third instance on macOS/launchd running 2026.4.5 is completely stable — this appears to be Linux/systemd specific
• 14s CPU in 8s wall time = the forked child is burning 100%+ CPU before killing the parent

Expected Behavior

Gateway should start and remain running without self-forking under systemd management.

Workaround

Downgrade to 2026.3.31 (not yet confirmed, planning to test).