ClawKit Logo
ClawKitReliability Toolkit

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.

Related status regressions: openclaw/openclaw#34292, openclaw/openclaw#34741.

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

What the Error Looks Like

systemctl --user unavailable: Failed to connect to bus: No medium found
Failed to connect to bus: No such file or directory
openclaw gateway install: error: user-level systemd is not running
DBUS_SESSION_BUS_ADDRESS not set, cannot contact systemd user instance

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

1

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.

2

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.

3

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:

Check all three requirements
# 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:

XDG_RUNTIME_DIR=(empty) → needs to be set
No such file or directory→ runtime dir doesn't exist yet, enable linger first
Linger=no→ linger disabled, user services won't persist
Linger=yes→ good — only XDG_RUNTIME_DIR might be missing

Fix A: Enable User Linger (Recommended)

This enables user-level systemd for your account, even when no interactive session is active.

Step 1 — Enable linger
sudo loginctl enable-linger $(whoami)
Step 2 — Set XDG_RUNTIME_DIR (add to ~/.bashrc)
echo 'export XDG_RUNTIME_DIR=/run/user/$(id -u)' >> ~/.bashrc
source ~/.bashrc
Step 3 — Install and start the gateway service
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.

Create a system-level service file
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
Enable and start the service
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.

Option 1: tmux
tmux new-session -d -s openclaw 'openclaw gateway start'
# Reattach later: tmux attach -t openclaw
Option 2: PM2
npm install -g pm2
pm2 start "openclaw gateway start" --name openclaw-gateway
pm2 save
pm2 startup  # generates the boot script

Verify It Works

Gateway status returns without D-Bus error
openclaw gateway status

Expected: Status: running — no "Failed to connect to bus" message

Service survives SSH disconnect

Expected: Disconnect SSH, reconnect, run openclaw gateway status — should still show running

Service starts on reboot
sudo reboot # then SSH back in after 1 minute

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:

Debug systemd-logind
# 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

npx clawkit-doctor@latest

Checks systemd availability, XDG_RUNTIME_DIR, linger status, and gateway health.

Did this guide solve your problem?