OpenClaw prints systemd user services are unavailable when it cannot reach your account's systemd user manager, which it needs to install the gateway as a background service. On a VPS that almost always means your shell has no user session bus: you switched accounts with su or sudo, lingering is off, or you are inside a container. Enable lingering, set XDG_RUNTIME_DIR, run as a non-root user, and retry openclaw gateway install.
Everything below is checked against OpenClaw 2026.9.8 (October 2026) and Hermes Agent v0.21.5. The commands come from the OpenClaw gateway runbook and the error text from OpenClaw's own source.
What does the full error look like?
From openclaw gateway status or openclaw gateway install, it usually arrives with the underlying systemd complaint first. This is the output from an Amazon Linux report, issue #11805:
systemctl --user unavailable: Failed to connect to bus: No medium found
systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.During onboarding with --install-daemon, OpenClaw does not fail. It skips the service and carries on, which is easy to miss in a long setup log:
Systemd user services are unavailable; skipping service install. Use a direct shell run (`openclaw gateway run`) or rerun without --install-daemon on this session.That second message comes from the non-interactive daemon installer. If you ignore it, the gateway runs only as long as your terminal does. Later service commands can report Gateway service not loaded., because no unit was ever installed.
Why does OpenClaw need systemd user services?
On Linux, openclaw gateway install writes a systemd user unit called openclaw-gateway.service. User units are run by a per-account manager (systemd --user) that you talk to through a session bus at /run/user/<uid>/bus. That manager normally starts when you open a real login session and stops when your last session ends. OpenClaw's setup wizard text spells out the consequence: "Without lingering, systemd stops the user session on logout/idle and kills the Gateway."
So the error is not about OpenClaw. It is about whether your account has a running user manager, and whether your current shell can find it.
Why does it happen on a VPS?
| Symptom | Cause | Fix |
|---|---|---|
Failed to connect to bus: No medium found over SSH | XDG_RUNTIME_DIR is not set, or no user manager is running | Enable lingering, then export XDG_RUNTIME_DIR |
Same error after sudo -u agent or su agent | Switching accounts does not give the target account its own login session | Enable lingering for that account, log in as it directly |
Failed to connect to bus: Permission denied | Your environment still points at another account's runtime directory, often inherited through sudo | Reset XDG_RUNTIME_DIR to your own /run/user/<uid> |
| No user bus on Debian or Ubuntu | The dbus-user-session package is missing | Install it |
System has not been booted with systemd | You are in a container or a host without systemd | Run the gateway in the foreground under your supervisor |
OpenClaw's doctor guide names the same three suspects: XDG_RUNTIME_DIR, DBUS_SESSION_BUS_ADDRESS, and dbus-user-session. And if you are logged in as root, fix that first: the docs say running the gateway and its agent commands as root "is unsafe and unsupported".
How do I fix it on a normal VPS?
Do this once per server. Replace agent with the non-root account that will own OpenClaw.
- Create the account if you are working as root, and turn on lingering so its user manager starts at boot and survives logout:
sudo adduser agent
sudo loginctl enable-linger agent
loginctl show-user agent --property=LingerThe last command should print Linger=yes.
- On Debian or Ubuntu, make sure the user bus exists:
sudo apt install dbus-user-session- Log in as that account directly (
ssh agent@your-server), not throughsudo -u. Then point your shell at its runtime directory and confirm the manager answers:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user statusA status tree means the manager is reachable. If you need the export in every session, add the line to ~/.profile. The docs also suggest systemctl --user start dbus.socket if the bus socket is not running.
- Install and start the service, then let doctor check the result. Doctor confirms that lingering is enabled for a user service:
openclaw gateway install
openclaw gateway status
openclaw doctorIf systemctl --user status works in the same shell but OpenClaw still says user services are unavailable, you may be on an old build. That false negative was reported against 2026.4.8 in issue #63561 and has since been closed, so update first. Our guide to fixing OpenClaw after an update covers the update itself.
When should I use a system-level unit instead?
The docs recommend a system unit for multi-user or always-on hosts. Start from the official user unit, add User=, and install it under /etc/systemd/system/. Use command -v openclaw to find the path for ExecStart:
[Unit]
Description=OpenClaw Gateway
After=network-online.target
Wants=network-online.target
StartLimitBurst=10
StartLimitIntervalSec=300
[Service]
User=agent
ExecStart=/usr/local/bin/openclaw gateway --port 18789
Restart=always
RestartSec=5
RestartPreventExitStatus=78
TimeoutStopSec=330
TimeoutStartSec=30
SuccessExitStatus=0 143
OOMPolicy=continue
KillMode=mixed
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway.serviceTwo things the docs warn about. Do not also let openclaw doctor --fix install a user service for the same port; set OPENCLAW_SERVICE_REPAIR_POLICY=external in the shell you run doctor from so the system unit owns the lifecycle. And run doctor as the User= account, after stopping the unit with systemctl.
A word on memory, because many copied units add MemoryMax=1024M. OpenClaw's hosting FAQ gives 1 GB as the absolute minimum and 2 GB or more as the recommendation. We measured one 2026.9.6 gateway at 991 MB resident, almost all of it private, so a hard 1 GB ceiling leaves no headroom and the kernel can kill the gateway on an ordinary busy turn. Size the VPS at 2 GB or more. If you want a guard rail, use a soft MemoryHigh well above that resident size with a MemoryMax higher still, and keep OOMPolicy=continue so one killed subprocess does not stop the whole gateway.
What do I do inside Docker?
A container has no user systemd at all, so openclaw gateway install cannot work there. OpenClaw's hint says so directly: "If you're in a container, run the gateway in the foreground". The official Docker setup already does this. Its compose file runs the gateway as the container's main process with restart: unless-stopped and init: true:
docker compose up -d openclaw-gateway
docker compose ps
sudo systemctl enable dockerThe last line matters on a VPS: a restart policy only brings the container back if the Docker daemon itself starts at boot.
How do I check the gateway survives logout and reboot?
Close every SSH session for the account, wait a minute, then check from a different admin account:
sudo loginctl user-status agent
ps -eo user,lstart,args | grep -i "[o]penclaw"The process should still be there. Then run sudo reboot, log back in with an admin account (not agent), and run the ps line again. The start time should match the boot, not your login. Finally, as agent:
openclaw gateway status
journalctl --user -u openclaw-gateway.service -bFor a system unit, drop --user and use sudo. If the gateway stops after a few days rather than at logout, that is a different problem; see why AI agents stop running.
What about Hermes Agent?
Hermes hits the same wall. Per the Hermes messaging docs, hermes gateway install creates a user unit called hermes-gateway, and lingering keeps it alive:
hermes gateway install
sudo loginctl enable-linger $USER
journalctl --user -u hermes-gateway -fOr install a boot-time system service that still runs as your user:
sudo hermes gateway install --system
sudo hermes gateway status --system
journalctl -u hermes-gateway -fThe trade-off: a system service needs root for every restart, including the automatic one at the end of hermes update, so the docs suggest a user service plus linger on a headless VM you never log into. Inside a container, Hermes refuses to install a user service; run hermes gateway run as the container's main process with a restart policy. On WSL2, the Hermes FAQ suggests running the gateway in tmux because WSL's systemd support is unreliable.
One trap is specific to the system service. When a systemd-supervised Hermes gateway fires a cron job, it tries to launch the job in its own scope with systemd-run --user --scope, so the job survives a gateway restart. That needs a user bus. Without one, Hermes v0.21.5 logs systemd-run --user --scope is unavailable and runs jobs as plain subprocesses that die if the gateway restarts mid job; setting cron.require_restart_safe_scope: true makes them fail instead (source). The remedy in Hermes's own message is sudo loginctl enable-linger <gateway-user> and a gateway restart. If the messaging side stops too, read our guide to a stopped Hermes messaging gateway.
What this looks like when someone else runs the gateway
On Qoren's managed OpenClaw hosting, none of the user session machinery is in the path. Each agent gets its own system-level unit, running as its own non-login system user, enabled at boot with Restart=always and OOMPolicy=continue. OpenClaw gateways get a soft MemoryHigh that never drops below 1200 MB, a hard ceiling above it, and no CPU quota written into the unit. The Hermes cron behaviour above is one reason Qoren upgrades Hermes deliberately rather than tracking every release: scheduled runs on agents with no user manager have to keep working before a new version goes out. Each agent's health is checked every few minutes, and a repair reinstalls the runtime while keeping its memory and keys.