Normal after update? | Friends of the Crustacean 🦞🤝 | Page 1

ashen prairie Apr 22, 2026, 4:52 PM

#

Is it normal to see this after an update via 'openClaw update'? How do I resolve this?

openclaw-agent@automation:~$ openclaw gateway restart

🦞 OpenClaw 2026.4.21 (f788c88)

Gateway service disabled.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: systemctl --user start openclaw-gateway.service
Start with: systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
Start with: If you're in a container, run the gateway in the foreground instead of openclaw gateway.

keen geyserBOT Apr 22, 2026, 4:52 PM

#

latent sleetBOT Apr 22, 2026, 4:52 PM

#

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

ashen prairie Apr 23, 2026, 3:25 AM

#

ashen prairie Is it normal to see this after an update via 'openClaw update'? How do I resolve...

@left siren

left sirenBOT Apr 23, 2026, 3:27 AM

#

Yeah, normal-ish.

That output usually means the update succeeded, but there is no managed Gateway service to restart, or systemd user services are unavailable on that box.

The usual fixes are:

If this is a normal Linux host and you want OpenClaw managed in the background

openclaw doctor
openclaw gateway install --force
openclaw gateway restart

If this is a headless SSH server

sudo loginctl enable-linger "$(whoami)"

#

openclaw gateway install --force
openclaw gateway restart

If this is a container

also normal
don’t use openclaw gateway restart
run openclaw gateway in the foreground under your container/supervisor, or restart the container itself

If you want, paste these and I can tell you which branch you’re in:

openclaw gateway status --deep
openclaw status

#

Docs:

ashen prairie Apr 23, 2026, 3:47 AM

#

Which part do you exactly want to see from 'openclaw gateway status --deep'?

left sirenBOT Apr 23, 2026, 3:47 AM

#

Full output is easiest, honestly.

If you want to trim it, paste these parts:

Runtime: ...
Connectivity probe: (or Read probe: if it shows that)
Capability: ...
Config (cli): ...
Config (service): ...
any lines about:
- systemd user services unavailable
- Service unit not found
- Service is loaded but not running
- Other gateway-like services detected
- Listening: ...
- any Fix: / Logs: / Restart log: hints

#

That’s the bit that tells me whether this is:

no service installed,
systemd user session not available,
CLI/service config mismatch,
or multiple gateways fighting each other.

If a token somehow appears, redact it, but the rest is fine to paste.

ashen prairie Apr 23, 2026, 3:50 AM

#

Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-23.log
Command: /home/openclaw-agent/.nvm/versions/node/v24.15.0/bin/node /home/openclaw-agent/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/openclaw-agent/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/openclaw-agent/.nvm/versions/node/v24.15.0/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

#

Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected)
Connectivity probe: ok
Capability: admin-capable

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
On a headless server (SSH/no desktop session): run sudo loginctl enable-linger $(whoami) to persist your systemd user session across logins.
Also ensure XDG_RUNTIME_DIR is set: export XDG_RUNTIME_DIR=/run/user/$(id -u), then retry.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

#

I have already updated the OpenClaw to v2026.4.21.

left sirenBOT Apr 23, 2026, 3:51 AM

#

Nice, that narrows it down a lot.

This does not look like a config mismatch. Config (cli) and Config (service) match.

The real issue is:

your systemd user service is disabled
the service is still pinned to an nvm-managed Node path
doctor is warning that there is no system Node 22.14+ / 24 available yet to migrate the service to

So my read is: the update didn’t really break OpenClaw, it exposed a brittle old service install.

I’d fix it in this order

1) Install a system Node
On Linux, preferably Node 24.

#

2) Repair the service

openclaw doctor --repair

3) Reinstall / refresh the gateway unit

openclaw gateway install --force

4) Re-enable and start it

systemctl --user enable --now openclaw-gateway.service

5) If this is a headless SSH box, enable linger once

#

sudo loginctl enable-linger "$(whoami)"

Why this order?

Because right now the service points at:

/home/openclaw-agent/.nvm/versions/node/v24.15.0/bin/node

That works until nvm changes, shell init differs, or upgrades move things around. OpenClaw is warning you away from that.

If you want, paste the output of openclaw doctor --repair next, and I can sanity check it before you touch the unit.

Docs:

https://docs.openclaw.ai/gateway/doctor

#

Ah, this is the key bit.

Good news:
Connectivity probe: ok + Capability: admin-capable means the Gateway itself is up and reachable.

So the failure is not “OpenClaw is down”.
The failure is: this shell cannot talk to systemctl --user.

In other words:

Gateway: running
user systemd control: broken/unavailable from this session

What that usually means

On a headless SSH box, the user systemd session is not fully available yet. The hints it printed are the right ones:

#

sudo loginctl enable-linger "$(whoami)"
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status openclaw-gateway.service

If that last command still errors, then you’re probably in one of these cases:

container / restricted environment
→ don’t use openclaw gateway restart, run the gateway under your supervisor/foreground instead
SSH session without a working user bus
→ fix lingering + XDG_RUNTIME_DIR, then retry

One more thing

You still have the older nvm-based service unit issue from the earlier output, so after systemd user control works, I’d still do:

#

openclaw doctor --repair
openclaw gateway install --force

So the short version is:

yes, the Gateway is alive
no, openclaw gateway restart won’t work from this session until the user systemd session is fixed

If you want, paste the output of:

systemctl --user status openclaw-gateway.service
echo "$XDG_RUNTIME_DIR"

#

and I can tell you which side of that split you’re on.

#

Yep, and that part is fine, you’re already on the current OpenClaw version.

The problem now is not the OpenClaw version.
It’s the service environment:

systemctl --user is unavailable from that session
your service unit is still using an old nvm-based Node path

So upgrading OpenClaw again won’t fix this.

What actually needs fixing

If this is a normal SSH/VPS Linux host

sudo loginctl enable-linger "$(whoami)"
export XDG_RUNTIME_DIR=/run/user/$(id -u)

#Normal after update?

I’d fix it in this order

Why this order?

What that usually means

One more thing

What actually needs fixing