Upgrading OpenClaw 2026.4.29 → 2026.5.4 (the self-killing gateway mystery)

• May 4, 2026
• openclaw  
• digitalocean  
• systemd  
• devops  
• linux  

Quick summary: After updating OpenClaw from 2026.4.29 to 2026.5.4, the gateway would start, the web UI would connect for a moment, and then it would get killed and restart in a loop. The cause turned out to be two different OpenClaw gateway services competing for the same port (18789): the correct system service (openclaw.service, running as user openclaw) and a stale root user service (openclaw-gateway.service, created long ago and still enabled for root). Disabling the stale root user service fixed it permanently.

The symptom

The upgrade succeeded, but the running gateway kept disconnecting. The control UI would briefly reconnect, then drop with:

disconnected (1006): no reason

What was actually happening

You had the intended system service:

/etc/systemd/system/openclaw.service

running as the dedicated openclaw user.

But there was also an old root user-level service:

/root/.config/systemd/user/openclaw-gateway.service

running as root and labelled:

OpenClaw Gateway (v2026.2.12)

That stale root service started its own OpenClaw gateway on port 18789. During startup, OpenClaw’s stale-gateway cleanup logic saw your proper running gateway, misclassified it as stale, and killed it. That caused the connect → disconnect loop.

The evidence (the smoking gun)

We found it by following the sequence:

OpenClaw started successfully
→ web UI connected briefly
→ gateway received SIGTERM
→ systemd restarted it
→ logs showed another root-owned process killing it
→ journal showed that process belonged to root's openclaw-gateway.service

The key log line was:

[restart] killing 1 stale gateway process(es) before restart
_SYSTEMD_USER_UNIT=openclaw-gateway.service
_CMDLINE=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

The fix

Stop and disable the stale root user service:

sudo XDG_RUNTIME_DIR=/run/user/0 systemctl --user stop openclaw-gateway.service
sudo XDG_RUNTIME_DIR=/run/user/0 systemctl --user disable openclaw-gateway.service

Then restart the real service:

sudo systemctl restart openclaw

After that, /etc/systemd/system/openclaw.service stayed up and the control UI stayed connected.

A safer upgrade pattern for next time

sudo systemctl stop openclaw
sudo XDG_RUNTIME_DIR=/run/user/0 systemctl --user stop openclaw-gateway.service 2>/dev/null || true
sudo npm install -g openclaw@latest
sudo systemctl start openclaw

Main lesson: using sudo npm install -g ... is fine for the global package install on your Droplet, but avoid running OpenClaw setup/start/onboard commands as root unless specifically required — otherwise you can end up with root-owned OpenClaw config and services under /root/.openclaw and /root/.config/systemd/user.