Summary

openclaw update / the managed update handoff can stop openclaw-gateway.service and then fail before restarting it, leaving OpenClaw completely unresponsive.

What happened

On a systemd-managed npm install, the update flow created/used openclaw-update.service. The logs showed:

Jun 10 11:11:05 dev systemd[1076]: Started openclaw-update.service - OpenClaw update.
Jun 10 11:11:05 dev do-update.sh[2696274]: [Wed Jun 10 11:11:05 EDT 2026] Stopping openclaw-gateway...
Jun 10 11:11:25 dev do-update.sh[2696274]: [Wed Jun 10 11:11:25 EDT 2026] Running openclaw update...
Jun 10 11:11:25 dev systemd[1076]: openclaw-update.service: Main process exited, code=exited, status=127/n/a
Jun 10 11:11:25 dev systemd[1076]: openclaw-update.service: Failed with result 'exit-code'.

After that, the gateway remained down:

openclaw-gateway.service loaded inactive dead OpenClaw Gateway

openclaw status could not get a live gateway response until the service was manually restarted.

Expected behavior

If the update handoff fails at any point after stopping the managed gateway, OpenClaw should make a best-effort attempt to restart the previous gateway service. The updater should not leave the primary gateway stopped just because the update command failed.

Actual behavior

The gateway was stopped first, then the transient update unit failed with exit 127, and no restart/fallback happened. This caused a full outage for channel responses.

Environment

• OS: Ubuntu Linux under systemd user services
• Install mode: npm, managed by mise Node install
• Before: OpenClaw 2026.6.1
• Latest/after manual repair: OpenClaw 2026.6.5
• Gateway unit: openclaw-gateway.service
• Gateway port: 18789

Local wrinkle that exposed this

This host also has a local systemctl wrapper that intentionally blocks accidental manual systemctl stop openclaw-gateway.service. That made one manual recovery path noisier, but the original outage came from the OpenClaw-managed transient update unit stopping the gateway and then failing before restart.

The updater should either:

1. use an absolute path/environment for the follow-up update command so the transient unit does not fail with command-not-found/PATH issues, and
2. install a trap/finally handler in the handoff script to restart openclaw-gateway.service if any post-stop step fails.

Recovery performed

Manual recovery was:

systemctl --user start openclaw-gateway.service
OPENCLAW_ALLOW_GATEWAY_STOP=1 openclaw update --yes --timeout 1200

The update then completed and restarted the gateway successfully.

Additional note

After recovery, restart-sentinel.json still reported an old update-restart-pending status from the failed handoff until it was manually moved aside. It may be worth clearing or superseding stale restart sentinels after a later successful update/restart.