Gateway Fails on Headless Linux — No User systemd
Common on Cloud VMs
Tracked in openclaw/openclaw#11805. On AWS EC2, GCP Compute, Azure VMs, and any SSH-accessed headless server, openclaw gateway status and openclaw gateway install fail because user-level systemd is not available.
You SSH into your server, run openclaw gateway install or openclaw gateway status, and get: "systemctl --user unavailable: Failed to connect to bus: No medium found." The gateway binary itself works fine — it's only the service management commands that break.
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Jump to Section
What the Error Looks Like
The key pattern: any openclaw gateway subcommand that tries to interact with systemd fails. But running the gateway binary directly (openclaw gateway start in the foreground) works fine. This confirms the issue is with systemd user sessions, not OpenClaw itself.
Why This Happens
No D-Bus session bus on headless servers
User-level systemd communicates over a D-Bus session bus socket at /run/user/<uid>/bus. On desktop Linux, this is created by the login manager. On headless servers accessed via SSH, no login manager runs — so the socket doesn't exist.
XDG_RUNTIME_DIR not set
The XDG_RUNTIME_DIR environment variable tells systemd where to find the user runtime directory. On many cloud images (Amazon Linux 2, minimal Ubuntu), this variable is not set for SSH sessions by default.
User linger is disabled
By default, systemd only starts user services when a user is logged in and stops them when the last session ends. Without "linger," user-level services cannot persist across SSH disconnections or run at boot without an active login.
Diagnose Your Setup
Run these checks to understand what's missing:
# 1. Is XDG_RUNTIME_DIR set? echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" # 2. Does the runtime directory exist? ls -la /run/user/$(id -u)/ 2>&1 # 3. Is linger enabled for your user? loginctl show-user $(whoami) 2>/dev/null | grep Linger
Reading the results:
Fix A: Enable User Linger (Recommended)
This enables user-level systemd for your account, even when no interactive session is active.
sudo loginctl enable-linger $(whoami)
echo 'export XDG_RUNTIME_DIR=/run/user/$(id -u)' >> ~/.bashrc source ~/.bashrc
openclaw gateway install --force openclaw gateway status
After enabling linger, user-level services persist across SSH disconnections and start automatically on boot. This is the cleanest fix for most server deployments.
Fix B: System-Level Service
If you prefer not to mess with user-level systemd, run OpenClaw as a system service instead. This is common in production deployments where the gateway should start at boot regardless of user logins.
sudo tee /etc/systemd/system/openclaw-gateway.service > /dev/null << 'EOF' [Unit] Description=OpenClaw Gateway After=network-online.target Wants=network-online.target [Service] Type=simple User=ubuntu Group=ubuntu WorkingDirectory=/home/ubuntu ExecStart=/usr/local/bin/openclaw gateway start Restart=on-failure RestartSec=5 Environment=HOME=/home/ubuntu Environment=NODE_ENV=production [Install] WantedBy=multi-user.target EOF
sudo systemctl daemon-reload sudo systemctl enable --now openclaw-gateway sudo systemctl status openclaw-gateway
Change User=ubuntu and WorkingDirectory to match your actual user. On Amazon Linux, the user is typically ec2-user. On Debian, it's admin.
Fix C: Manual Process Management
If you don't want to use systemd at all, run the gateway in a detached screen/tmux session or use a process manager like PM2.
tmux new-session -d -s openclaw 'openclaw gateway start' # Reattach later: tmux attach -t openclaw
npm install -g pm2 pm2 start "openclaw gateway start" --name openclaw-gateway pm2 save pm2 startup # generates the boot script
Verify It Works
Expected: Status: running — no "Failed to connect to bus" message
Expected: Disconnect SSH, reconnect, run openclaw gateway status — should still show running
Expected: openclaw gateway status shows running without manual intervention
Still Stuck?
If linger is enabled and XDG_RUNTIME_DIR is set but it still fails, check if systemd-logind is actually running:
# Is logind running? systemctl status systemd-logind # Is the user session registered? loginctl list-sessions # Check the bus socket directly ls -la /run/user/$(id -u)/bus
On some minimal cloud images (Alpine, Busybox-based), systemd is not installed at all. In that case, skip to Fix B (system-level service) or Fix C (manual management).
Run the Doctor
Checks systemd availability, XDG_RUNTIME_DIR, linger status, and gateway health.
Related Issues
Other server deployment problems:
Fix It Faster With Our Tools
Config Wizard
Generate a production-ready clawhub.json in 30 seconds.
Cost Simulator
Calculate your agent burn rate before you get surprised.
Skill Registry
Browse 9,000+ verified plugins for your OpenClaw agent.
Gateway Monitor
Detect token spikes and gateway incidents before users complain.
Skill Finder
Describe your use case and find the right Claude Code skill instantly.
Did this guide solve your problem?