Systemd user services are unavailable. Skipping lingering checks and service install.

[forest copper]

I'm running openclaw on a fresh debian LXC and got this message when installed, should I be concerned? What does this mean, how can i correct it?

[violet jasper]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[vital ermine]

That message is basically: the onboarding wizard tried to install the Gateway as a background service via systemd --user, but your container environment doesn’t have a working “user systemd / user D-Bus session”, so it skipped the service install (and the lingering check).

So:

• Should you be concerned? Not really. OpenClaw can still run fine.
• What it means: You won’t get an auto-starting systemd user service. After a reboot/logout, the gateway won’t magically come back unless you run it some other way.
• What to correct: Either run the gateway manually/supervised, or fix systemd-user-session support in the LXC so systemctl --user works.

Docs reference (this exact step): https://docs.openclaw.ai/reference/wizard#daemon-install

Option A (quick / common on LXC): just run it yourself

Use foreground to confirm everything works:

openclaw gateway run

Then keep it alive with whatever you use in the container (tmux/screen/supervisord), or run OpenClaw in a setup that provides proper service management (VM/Docker/Podman depending on your host).

Option B (make the wizard’s systemd user service work)

You need systemd as PID 1 + a user session with DBus (this is what’s often missing in LXC/headless/root-only setups).

Run these and paste the output if you want help diagnosing:

openclaw --version
ps -p 1 -o comm=
systemctl --user status
echo $XDG_RUNTIME_DIR
echo $DBUS_SESSION_BUS_ADDRESS

If you do get systemctl --user working, then rerun the service install:

openclaw gateway install
openclaw gateway start

openclaw gateway status

If you tell me whether your Debian LXC is running systemd inside the container (and whether you’re running OpenClaw as root or a normal user), I can point you to the most likely fix path.

[forest copper]

openclaw@openclawproxmox:~$ openclaw --version
2026.3.1
openclaw@openclawproxmox:~$ ps -p 1 -o comm=
systemd
openclaw@openclawproxmox:~$ systemctl --user status
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
openclaw@openclawproxmox:~$ echo $XDG_RUNTIME_DIR

openclaw@openclawproxmox:~$ echo $DBUS_SESSION_BUS_ADDRESS

[vital ermine]

Yep — your output explains it perfectly:

• systemd is PID 1 ✅
• but you don’t have a systemd “user session” / user D‑Bus for that shell ❌ ($XDG_RUNTIME_DIR + $DBUS_SESSION_BUS_ADDRESS are empty)
• so systemctl --user … can’t talk to the per-user service manager, and the onboarding wizard skips installing the systemd user unit + lingering.

This is common in LXC / minimal Debian / shells that aren’t PAM-logind sessions (e.g. su, some SSH setups, etc.). It’s not dangerous — it just means no auto-start service was installed.

Fix (make systemctl --user work)

1. Check logind is actually running:

sudo systemctl status systemd-logind --no-pager
loginctl list-sessions

2. Make sure the pieces that create user sessions are installed (Debian often needs these on “fresh/minimal” images):

sudo apt update
sudo apt install -y libpam-systemd dbus-user-session

3. Log out and log back in (important), then verify you now get a runtime dir:

echo "$XDG_RUNTIME_DIR"
systemctl --user status

You should see something like /run/user/1000.

4. Then retry installing the gateway service:

openclaw gateway install
openclaw gateway start

openclaw gateway status

If XDG_RUNTIME_DIR is still empty after a fresh SSH login, tell me how you’re entering the container (SSH directly as openclaw vs su from root, etc.) and paste:

grep -E '^UsePAM' /etc/ssh/sshd_config 2>/dev/null || true

Docs context for why the wizard tries this: https://docs.openclaw.ai/reference/wizard#daemon-install

[forest copper]

i get the same two errors when running this command

[vital ermine]

That error means you’re still not in a real “login session” for that user, so systemd never set up the per-user runtime dir + D‑Bus session that systemctl --user talks to.

In LXC this is super common if you’re entering the container via Proxmox “Console” / pct exec / lxc-attach (those don’t go through PAM/logind), so you get:

• $XDG_RUNTIME_DIR empty
• $DBUS_SESSION_BUS_ADDRESS empty
• ⇒ systemctl --user … can’t connect

Quick check: how are you getting into the container?

Run:

echo "$SSH_CONNECTION"
tty

• If SSH_CONNECTION is empty and tty looks like pts/... from a container attach/console, you’re in the “no login session” case.

Fix path A (recommended): SSH in “normally”, then install the user service

1. Make sure SSH server is installed/running in the container:

sudo apt install -y openssh-server
sudo systemctl enable --now ssh

2. SSH into the container as the openclaw user (from your host machine):

ssh openclaw@<container-ip>

3. Now re-check:

echo "$XDG_RUNTIME_DIR"
systemctl --user status

You should see /run/user/<uid>.

4. Then:

openclaw gateway install
openclaw gateway start
openclaw gateway status

Fix path B (pragmatic for LXC): don’t use systemd user services

If you don’t want to fight user sessions in containers, you can just run the gateway manually (tmux/screen), or set up a system-level service instead. The onboarding warning is not a functional problem — it only affects “auto-start as a user service”.

If you tell me whether you’re currently entering via Proxmox console / pct exec vs SSH, I can point you to the cleanest option for your setup.

[forest copper]

ok for nayone that sees this just make a VM and not a CT its easier 😭

and more secure anyway

[vital ermine]

Yeah… unfortunately that tracks. In LXC/CTs you can have systemd as PID 1 but still not have a proper user session bus (XDG_RUNTIME_DIR / DBUS_SESSION_BUS_ADDRESS), so the wizard can’t install the systemd user service cleanly.

A VM is the “it just works” path.

If you (or someone reading later) still wants to stay on a CT, the two workable options are:

• run OpenClaw manually / under a supervisor (tmux/screen/supervisord), or
• set it up so you log in via real SSH+PAM and have dbus-user-session + libpam-systemd so systemctl --user works.

If you end up moving to a VM and it fixes it, please mark the message that helped as the solution (right‑click → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

“More secure” is mostly true, but with a big asterisk:

• VMs give you stronger isolation by default (separate kernel). If the guest gets popped, it’s generally harder to break out to the host.
• LXC/CTs share the host kernel, so a kernel/container-escape bug is the scary case. That said, an unprivileged CT with tight settings can still be pretty solid for many homelab setups.

For OpenClaw specifically, the practical win is: VMs avoid a ton of systemd user-session / D-Bus weirdness, so the “install systemd user service + lingering” path tends to Just Work.

If you want a short rule of thumb for folks reading later:

• Want least hassle (and good isolation)? VM.
• Want efficiency and you know your Proxmox/LXC hardening? Unprivileged CT, but expect to manage the gateway process differently.

If this thread is basically resolved, please mark the solution (right-click the message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.