openclaw - 💡(How to fix) Fix Feature request: openclaw update should support system-level systemd units (not just user-level) [1 comments, 2 participants]

Summary

openclaw update generates a detached restart-script that uses systemctl --user restart <unit>. Operators running OpenClaw under a system-level systemd unit (/etc/systemd/system/openclaw.service, restarted via sudo systemctl restart openclaw) are silently bypassed by this restart path: the script either runs and fails harmlessly under --user, or the user-level controller doesn't exist at all. Either way, the gateway PID is unchanged after a successful package install.

Reproduction

1. Install OpenClaw under a system-level systemd unit (typical hardened VPS layout):

   /etc/systemd/system/openclaw.service

2. Run openclaw update --tag <newer-version> --yes from any context (external SSH or in-lane both demonstrate this).
3. Observe: package install completes, systemctl --user restart fires (silently fails on a system-level setup), gateway PID is unchanged.
4. Operator must manually invoke sudo systemctl restart openclaw.service from a fresh shell.

Root cause

In the openclaw update restart-script generator, the Linux script template hardcodes systemctl --user restart. The OPENCLAW_SERVICE_MARKER env-var guard is also missing on system-level unit installs, so the in-process "don't run package updates inside gateway service" check doesn't fire either.

Proposal

Three complementary changes:

Change 1: auto-detect and use system-level path when appropriate.

• At restart-script generation time, detect whether the active openclaw.service belongs to a system-level systemd unit (path /etc/systemd/system/<name> or output of systemctl show <unit> -p FragmentPath indicating system-level).
• If system-level: emit a script that uses sudo systemctl restart <unit> (assuming sudo is configured for the user; this is the standard pattern for system-level deploys).
• If user-level: keep current systemctl --user restart behavior.

Change 2: add explicit --restart-via <mode> flag for operator override.

openclaw update --tag X --yes --restart-via systemd-system
openclaw update --tag X --yes --restart-via systemd-user
openclaw update --tag X --yes --restart-via none           # equivalent to --no-restart
openclaw update --tag X --yes --restart-via auto-detect    # default

Together: auto-detect handles 95% of installs; flag handles edge cases and gives explicit control.

Change 3 (safety guard): if systemctl --user restart is selected but the active gateway PID belongs to a system-level unit, fail loudly instead of silently leaving old PID live.

Why this matters

System-level systemd is the standard hardened-VPS deployment pattern (Ubuntu/Debian/RHEL all default to system units for production services). Any operator following normal Linux production deployment guidance will hit this. Currently the only signal the restart didn't take is observing the gateway PID afterward — which most operators don't do because the install command exits 0.

Empirical evidence

From 4.29 cutover at 2026-05-01 04:16-04:21Z UTC and prior 4.26 cutover ~2026-04-28:

• Production unit: system-level at /etc/systemd/system/openclaw.service
• OPENCLAW_SERVICE_MARKER not in gateway process env (auto-detection on system-level units doesn't set it)
• openclaw update --yes package install succeeded; PID unchanged on both cutovers
• Workaround: manual sudo systemctl restart openclaw.service from external SSH session

Sister filing

Companion to issue #75691 (PPID-ancestry guard for in-lane invocation). Together they close both halves of the silent-restart-failure surface area.