Description

openclaw gateway restart and openclaw gateway stop fail in container environments (Docker, Podman, LXC, etc.) that lack systemd. Both commands immediately exit with:

Gateway service disabled.
Start with: openclaw gateway install
...
If you're in a container, run the gateway in the foreground instead of `openclaw gateway`.

The gateway process is running and listening on its configured port, but runServiceRestart/runServiceStop check service.isLoaded() first — which returns false when no systemd/launchd unit exists — and bail before attempting any action.

Root Cause

lifecycle-core.ts requires the service to be "loaded" (systemd enabled / launchd registered) before proceeding with restart or stop. In containers without a service manager, isLoaded() always returns false, so both paths are blocked.

However, the gateway process already handles SIGUSR1 natively for graceful in-process restarts (via the run-loop's onSigusr1 handler), and SIGTERM for graceful shutdown. The signal-based mechanisms work regardless of the service manager — the CLI just can't reach them.

Steps to Reproduce

1. Run OpenClaw in a Docker container (or any environment without systemd)
2. Start gateway: openclaw gateway --port 18789
3. In another shell: openclaw gateway restart → fails with "Gateway service disabled"
4. openclaw gateway stop → same failure, process still running

Expected Behavior

• openclaw gateway restart should discover the running gateway process (via port-based PID discovery) and send SIGUSR1 for graceful restart
• openclaw gateway stop should discover the process and send SIGTERM for graceful shutdown
• Both should work transparently whether a service manager is present or not

Environment

• Container: Docker / Podman / LXC (any environment without systemd)
• OS inside container: Debian, Ubuntu, Alpine, etc.
• Gateway started via: openclaw gateway --port 18789 (foreground)