openclaw - 💡(How to fix) Fix openclaw gateway stop returns 'Gateway service disabled' without killing a foreground-launched gateway [1 participants]

Summary

In plain English: if you start the gateway in foreground (openclaw gateway, not openclaw daemon start), then later run openclaw gateway stop, the stop command returns "Gateway service disabled" — but doesn't actually kill the running gateway. The process keeps running and port 18789 stays bound. You have to fall back to kill -TERM <pid> from inside the pod to actually stop it. This is confusing on first encounter; the stop command's output sounds successful when it isn't.

Repro

# 1. Start gateway in foreground (typical for in-pod use, no systemd available):
openshell sandbox exec -n nemoclaw-deepobs --timeout 0 -- /usr/local/bin/openclaw gateway > /tmp/gw.log 2>&1 &

# Wait for "ready" line
grep -q "ready" /tmp/gw.log

# 2. Try to stop:
openshell sandbox exec -n nemoclaw-deepobs --timeout 30 -- /usr/local/bin/openclaw gateway stop

Output:

[restart] lsof failed during initial stale-pid scan for port 18789: ENOENT
Gateway service disabled.

Process is unaffected:

openshell sandbox exec -n nemoclaw-deepobs --timeout 10 -- /bin/bash -c 'pgrep -af openclaw'
# 50  openclaw
# 63  openclaw-gateway       ← STILL ALIVE

Port 18789 is still LISTEN. To actually stop the gateway, we had to:

openshell sandbox exec -n nemoclaw-deepobs --timeout 10 -- /bin/bash -c 'kill -TERM 63'

After SIGTERM, the gateway dies cleanly within ~2s and port 18789 frees up.

Root cause (best guess)

openclaw gateway stop is wired to a service-manager wrapper (launchd / systemd / schtasks). When the gateway was started directly (openclaw gateway foreground, NOT openclaw daemon start), there's no service definition to disable. The stop command silently no-ops on the live process and reports success.

The "Gateway service disabled" message reinforces the misperception — the user reads it as "the gateway has been disabled" but it actually means "the (non-existent) service-manager registration has been disabled".

The [restart] lsof failed during initial stale-pid scan for port 18789: ENOENT line gives a hint that something is off (no lsof in the busybox-ish sandbox utils), but it's a non-error-coded line and easy to miss.

Why it matters

In any sandboxed runtime that doesn't have systemd (NemoClaw, Docker-in-Docker, minimal Linux containers, etc.), the foreground gateway launch is the norm — not the exception. openclaw daemon start is unusable in those environments because there's no service manager. So openclaw gateway stop falling silently for foreground launches is the common case in sandboxed deployments, not an edge case.

Suggested fix (in priority order)

1. Find the running pid and SIGTERM directly

openclaw gateway stop could fall back to:

• Read the gateway's lock file (if one is written; we didn't check).
• Probe port 18789 for the listening pid.
• kill -TERM <pid>; wait for clean exit; report success/failure.

If no service-manager registration AND no running process found, then the current "Gateway service disabled" / "no gateway running" message is correct.

2. Clear messaging when neither service nor process found

No gateway service registered (use `openclaw daemon start` for service-managed
runs). Found running gateway process at pid 63 — SIGTERM sent.

vs:

No gateway service registered (use `openclaw daemon start` for service-managed
runs). No running gateway process found.

3. (Minimum) clarify "Gateway service disabled" message

If the actual stop functionality is too disruptive to add, at least change the message to make clear what happened:

-Gateway service disabled.
+Service-manager registration disabled. (No effect on a directly-started
+`openclaw gateway` process — use `kill -TERM <pid>` to stop those.)

Alternatives considered

• Hard-fail with "no service to disable; if you started gateway in foreground use kill instead": clearer than current, less helpful than #1.
• Make openclaw gateway start register itself with a sentinel file, so stop knows to look for it: pollutes the FS, doesn't really help across crash/recover paths.

Test plan

After fix #1:

• Start gateway in foreground; openclaw gateway stop should kill it within ~5s.
• Start with openclaw daemon start; openclaw gateway stop should disable the service AND kill the process.
• Run openclaw gateway stop with no gateway running; should return clean "no gateway running" message and exit 0 (or exit 1, by preference).

Risk / blast radius

Small. The additional pid-discovery + SIGTERM logic is straightforward. Edge cases:

• Gateway pid found but not actually our gateway (port collision): low risk because port 18789 is gateway-specific. Could verify by reading the process command line.
• Multiple gateways running (unusual but possible in dev environments): SIGTERM all matching pids, or refuse and ask for --all.

Open questions for maintainers

1. Is there already a lock file or pid file the gateway writes? That would simplify the fix considerably.
2. Acceptable to make openclaw gateway stop SIGTERM ANY listener on 18789, or should it require a more specific match?
3. The companion openclaw gateway start — does it also work for foreground use, or is it strictly service-manager-only? (We've been using bare openclaw gateway for foreground; start/stop symmetry would be cleaner.)

Tested-against

• OpenClaw v2026.4.9
• NemoClaw v0.0.26 sandbox (no systemd — foreground gateway is the only viable launch mode)

Severity

Medium. Doesn't block anything (the workaround is kill -TERM), but anyone debugging gateway issues in-pod will hit this immediately and lose time figuring out why "stop" didn't stop.