openclaw status --deep reports "systemd user not installed" false positive when gateway runs under systemctl system

Target repo: openclaw/openclaw Filer: islandpreneur007 Draft status: ready for review + file Date drafted: 2026-05-21 First observed: S41 backlog item, ~April 2026 Confirmed still present: 2026-05-21 on 2026.5.19 (a185ca2)

Summary

openclaw status --deep reports "Gateway service: systemd user not installed" and "Node service: systemd user not installed" as false positives when the gateway is actually running healthy under systemctl system-level units (not systemctl --user).

Reproduction

Environment: gateway running as a system-level systemd unit (e.g. /etc/systemd/system/openclaw.service), not a user-level unit.

# Confirm gateway is alive under system systemd:
systemctl show openclaw --property=MainPID,NRestarts,ActiveState --value
# Output: <pid> 0 active

# Confirm /readyz is green:
curl -s http://127.0.0.1:43127/readyz | jq -c '{ready, deg: .eventLoop.degraded}'
# Output: {"ready":true,"deg":false}

# Run openclaw status --deep:
openclaw status --deep 2>&1 | grep -iE "systemctl|user|error|fail"
# Output:
# │ Gateway service      │ systemd user not installed     │
# │ Node service         │ systemd user not installed     │

False positive: the gateway IS running, just under system systemd instead of user systemd.

Expected behavior

status --deep should detect that the gateway is running and report its actual systemd scope (system vs user), OR fall back to checking system-level systemd if user-level returns nothing, OR at minimum not report "not installed" when the actual process is alive and /readyz is reachable.

Observed behavior

The probe checks systemctl --user and reports "not installed" when that scope has no openclaw unit. It does not fall back to system-level scope or to alternative detection mechanisms (PID lookup, /readyz reachability, etc.).

Operational impact

• New operators see "Gateway service: systemd user not installed" and assume installation is broken when it's actually fine.
• Adds noise to legitimate status --deep debugging when the operator is investigating other issues.
• Forces operators to know-the-quirk before they can trust status --deep output.

Environment

• OpenClaw version: 2026.5.19 (a185ca2)
• Host: Ubuntu 24.04, gateway running under systemctl system unit
• Install method: ~/.npm-global (npm i -g openclaw)
• Service unit: /etc/systemd/system/openclaw.service
• No conflicting user-level openclaw unit installed

Suggested fix direction

Either:

1. Probe BOTH systemctl --user and systemctl system scope; report whichever has the openclaw unit + scope; only report "not installed" when BOTH return nothing.
2. Use PID + /readyz reachability as the primary alive signal; treat systemd presence as supplementary information.
3. Document that status --deep is user-systemd-scope-only and add a --system flag for system-scope probing.

Option 1 is the cleanest — status --deep should not care which systemd scope hosts the unit; the operator just wants to know if the gateway is up.

Related context

• This was queued in our S41 backlog (~April 2026) as a "needs upstream filing" candidate.
• Re-verified on 2026.5.19 today (2026-05-21); still present.
• Not aware of any related upstream issue. Did not find one in the openclaw issue tracker via brief search.

Related issues

(None identified — please link if there's a known parent issue.)