Bug type

Systemd user service lifecycle / Linux root shell edge case

Summary

When running openclaw gateway stop/start/status from a root shell that still has SUDO_USER/SUDO_UID/SUDO_GID set from a previous sudo escalation, the CLI targets the sudo user's systemd user scope instead of the actual root user's systemd user service.

In this environment the gateway service is installed and running as root's systemd user service at:

/root/.config/systemd/user/openclaw-gateway.service

But openclaw gateway stop reports success without stopping the root service, and openclaw gateway start fails trying a scope where the unit is not found. Removing the stale SUDO_* variables makes the same OpenClaw commands work correctly.

Environment

OpenClaw 2026.5.7 (eeef486)
OS: Linux server / headless root shell
Install method: npm global
Binary: /usr/bin/openclaw -> /usr/lib/node_modules/openclaw/openclaw.mjs
Effective user: uid=0(root)
HOME=/root
USER=root
LOGNAME=root
XDG_RUNTIME_DIR=/run/user/0

The shell also had stale sudo variables:

SUDO_USER=<sudo-user>
SUDO_UID=1000
SUDO_GID=1000
SUDO_COMMAND=/bin/bash

Service file

[Unit]
Description=OpenClaw Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/openclaw gateway --port 18789
Restart=always
RestartSec=5
TimeoutStopSec=30
TimeoutStartSec=30
SuccessExitStatus=0 143
KillMode=control-group
Environment=HOME=/root
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
EnvironmentFile=/root/.config/openclaw/gateway.env

[Install]
WantedBy=default.target

Steps to reproduce

1. Have a root-owned OpenClaw gateway user service installed:

systemctl --user enable --now openclaw-gateway.service

2. In a root shell that still has SUDO_USER/SUDO_UID/SUDO_GID set, run:

openclaw gateway stop
systemctl --user status openclaw-gateway.service --no-pager
ss -ltnp | grep 18789 || true
openclaw gateway start
openclaw gateway status

Actual behavior

openclaw gateway stop prints success:

Gateway service disabled.

But the service is still running under root's user manager with the same PID:

● openclaw-gateway.service - OpenClaw Gateway
     Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
     Active: active (running)
   Main PID: 4067986 (openclaw)

The port is still listening:

LISTEN 0 511 127.0.0.1:18789 users:(("openclaw",pid=4067986,fd=25))
LISTEN 0 511 [::1]:18789 users:(("openclaw",pid=4067986,fd=26))

openclaw gateway start then fails:

Gateway start failed: Error: systemctl restart failed: Failed to restart openclaw-gateway.service: Unit openclaw-gateway.service not found.
Tip: openclaw gateway install
Tip: openclaw gateway
Tip: systemctl --user start openclaw-gateway.service

openclaw gateway status can also report contradictory service state:

Service: systemd user (disabled)
Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
Connectivity probe: ok
Listening: 127.0.0.1:18789

Expected behavior

When the effective user is root, HOME=/root, USER=root, LOGNAME=root, and the gateway unit file exists under /root/.config/systemd/user, gateway lifecycle commands should target root's systemd user manager, not a stale SUDO_USER scope.

At minimum, if OpenClaw chooses to target SUDO_USER, it should not report success for stop when the actual configured/root service and listener remain active.

Workaround confirmed

Unsetting stale sudo variables makes lifecycle commands work correctly:

env -u SUDO_USER -u SUDO_UID -u SUDO_GID -u SUDO_COMMAND openclaw gateway stop
env -u SUDO_USER -u SUDO_UID -u SUDO_GID -u SUDO_COMMAND openclaw gateway start
env -u SUDO_USER -u SUDO_UID -u SUDO_GID -u SUDO_COMMAND openclaw gateway status

With those variables removed, openclaw gateway stop actually stops the root user service:

Stopped systemd service: openclaw-gateway.service
Active: inactive (dead)

And openclaw gateway start/status are correct:

Restarted systemd service: openclaw-gateway.service
Service: systemd user (enabled)
Runtime: running (pid 4074583, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok

Suspected cause

The systemd user scope selection appears to prefer SUDO_USER when effective uid is root. That is useful for sudo openclaw ... flows, but it is incorrect for an already-root shell managing a root-owned service under /root/.config/systemd/user.

A possible guard would be to ignore SUDO_USER when the root-owned unit path exists and HOME resolves to /root, or otherwise prefer the owner implied by the resolved service unit path/config path.