#Bot on VPS always stops responding after a while

1 messages · Page 1 of 1 (latest)

lilac stag
#

Its connected to telegram. Since it stops responding I connect to VPS and check status: systemctl --user status openclaw-gateway . Status is "active" always. But after running this command, it automatically wakes the telegram bot up and he starts responding without further action from me.
I dont understand why only checking status wakes it up, and how to have it active all the time?

limpid voidBOT
#

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

wary aspenBOT
#

systemctl --user status … shouldn’t “wake up” a healthy running process. When it looks like it does, the usual cause on VPS is: your Gateway is a systemd user service and the user manager gets stopped when you log out / go idle (lingering off). Then when you SSH in and run systemctl --user …, systemd starts your user manager again → the Gateway starts again → Telegram “suddenly works”.

This exact gotcha is called out here: https://docs.openclaw.ai/start/setup#linux-systemd-user-service

Fix (make it actually always-on)

On the VPS, as a sudo-capable account:

openclaw --version
loginctl show-user $USER -p Linger
sudo loginctl enable-linger $USER
systemctl --user restart openclaw-gateway.service

If you’re running the service under a dedicated user (e.g. openclaw), run enable-linger for that user instead:

# 
sudo loginctl enable-linger openclaw

Quick sanity checks (paste output if it still happens)

Run these when it’s “stuck” (before you do anything else):

openclaw gateway status
openclaw channels status --probe
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If gateway status is running but Telegram is disconnected, the logs usually tell us why (common: flaky egress/IPv6/DNS; see the “Polling or network instability” section: https://docs.openclaw.ai/channels/telegram#polling-or-network-instability).

lilac stag
# 
openclaw --version
2026.3.1

loginctl show-user $USER -p Linger
Linger=no

I'm connected with root. I should run loginctl enable-linger $USER as is, no need to replace $USER with something else?

wary aspenBOT
#

Yep — but only if the Gateway is actually running as that same user.

Since you’re SSH’d in as root, $USER expands to root, so:

loginctl enable-linger $USER

is equivalent to:

loginctl enable-linger root

That will keep root’s systemd user manager (and any systemctl --user … services under it, like openclaw-gateway.service) running after you log out.

Do this (as root)

# 
loginctl enable-linger root
loginctl show-user root -p Linger

systemctl --user restart openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager

One important caveat

If you meant to run OpenClaw under a non-root user (recommended), then you need to enable lingering for that user instead, e.g.:

loginctl enable-linger openclaw

If you tell me what username you installed/started the gateway under (and what systemctl --user status openclaw-gateway.service shows for Main PID), I can sanity-check you’re enabling linger for the right account.

lilac stag
#

how do I know which user is openclaw running with?

wary aspenBOT
#

For a systemd user service, the rule is simple:

  • systemctl --user … controls the current user’s systemd user manager
  • so the unit runs as that user

So if you’re running systemctl --user status openclaw-gateway while logged in as root, it’s almost certainly running as root.

Confirm via PID → user

PID=$(systemctl --user show openclaw-gateway.service -p MainPID --value)
echo "$PID"
ps -o user,uid,cmd -p "$PID"

Or check where the unit file lives