openclaw - 💡(How to fix) Fix openclaw gateway stop is a no-op against foreground-launched gateway (no service-manager fallback) [1 comments, 1 participants]

In plain English: if you start the gateway in foreground (e.g., openclaw gateway directly, no daemon wrapper), then run openclaw gateway stop to clean up, the stop command reports "Gateway service disabled" and exits success — but the running gateway process is still alive and the port is still bound. You have to find the pid via ps and kill it manually. Anyone debugging the gateway from inside a sandbox or a container without systemd hits this immediately.

Problem

openclaw gateway stop does not actually stop a foreground-launched gateway:

# Terminal 1
$ openclaw gateway     # foreground; logs "[gateway] ready (6 plugins, 2.0s)"

# Terminal 2
$ openclaw gateway stop
[restart] lsof failed during initial stale-pid scan for port 18789: ENOENT
Gateway service disabled.

$ ps aux | grep openclaw-gateway
sandbox  78 ... openclaw-gateway     # still alive
$ ss -tlnp | grep 18789
LISTEN 0 511 0.0.0.0:18789           # still bound

$ kill -TERM 78                       # actually stops it

Reproducer

In any environment without systemd / launchd (NemoClaw sandbox pod, plain Linux container, docker exec, WSL2, etc.):

1. Start gateway in foreground: openclaw gateway (or via openshell sandbox exec --timeout 0 -- openclaw gateway).
2. From another shell, run openclaw gateway stop.
3. Output: Gateway service disabled. (success).
4. ps aux | grep openclaw — the gateway process is still running.
5. Port 18789 still bound.

Tested-against: OpenClaw v2026.4.9 inside a NemoClaw v0.0.26 sandbox. Likely reproduces on any host without a systemd / launchd / schtasks service registration.

Root cause

openclaw gateway stop appears to be wired only to a service-manager wrapper (launchd / systemd / schtasks). When the gateway was started directly (openclaw gateway, not openclaw daemon start), there is no service definition for the stop command to disable. The command silently no-ops on the live process. The lsof scan fails (ENOENT because lsof isn't installed in the sandbox) and the command continues without checking for an actual listener.

Proposed fix

openclaw gateway stop should:

1. Check for a service-manager registration first (launchd/systemd/schtasks). If found, disable as today.
2. If no service registration exists, fall back to:
   • Read ~/.openclaw/gateway.pid (or the lock file's pid, if it exists).
   • Send SIGTERM to that pid; wait up to N seconds; SIGKILL if still alive.
   • Verify the port is no longer bound.
3. If neither approach finds a running gateway, error clearly:

   No running gateway found (no service registration, no lock file).
   If a gateway is running but not registered, find its pid via `ps aux | grep openclaw-gateway` and kill it manually.

openclaw gateway (foreground) should also write its pid to a lock file at startup so the stop command can find it.

Alternatives considered

• Add a --force flag to scan all listeners on port 18789 and kill the owner. Risky — could match unrelated processes; lock file is safer.
• Document the gap and tell users to use kill manually. Existing path; high friction.
• Detect "no service manager available" at startup and refuse to run foreground without an explicit --no-daemon flag. Too prescriptive — many container/sandbox use cases don't have a service manager.

Test plan

• Foreground gateway + gateway stop on a host without systemd: should kill the process, port should be released.
• Daemon gateway (openclaw daemon start) + gateway stop: should disable the service as today.
• Stop with no gateway running: should print a clear "no gateway found" message and exit non-zero.

Risk / blast radius

• Pid-file semantics: stale pid file from a crashed gateway needs careful handling — should match the running process's start time before killing to avoid SIGKILL'ing an unrelated process that recycled the pid.
• --force kills: if the lock-file approach is used, no force-kill needed. Risk minimized.
• Backwards compat: existing daemon-mode users see no change.

Open questions

1. Is there already a lock file written by openclaw gateway? (Saw /tmp/openclaw-998/openclaw-2026-04-27.log in the run — that's a log file, not a lock. Couldn't find a pid file in the pod.)
2. Preferred location for the lock file — ~/.openclaw/gateway.pid, /tmp/openclaw-<uid>/gateway.pid, or platform-specific?
3. Should gateway stop print a verbose summary on success (pid killed, port released) so operators have confirmation?

Sibling findings filed/being filed: plugin install path rejection (#72938), mDNS crash (#72939), async register truncated, double plugin-load timing.