Connection refused | Friends of the Crustacean 🦞🤝 | Page 1

pseudo thornBOT Mar 8, 2026, 10:04 PM

#

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

lone ploverBOT Mar 8, 2026, 10:06 PM

#

That channel 3: open failed: connect failed: Connection refused line is from SSH port-forwarding, not from OpenClaw itself.

It means: something on your machine tried to use the SSH tunnel, and SSH then tried to connect on the remote side to 127.0.0.1:18789 — but nothing was listening there, so the remote kernel returned “connection refused”.

The confusing part is your log also says the Gateway is “listening on ws://127.0.0.1:18789”. The usual reasons those can both be true:

Docker / container boundary

If the Gateway is listening on 127.0.0.1 inside a container, then the host 127.0.0.1:18789 can still be closed → SSH forwarding to the host will fail.
Fix: in containerized setups you generally need the gateway to bind to something reachable from outside the container (e.g. gateway.bind: "lan") and keep auth enabled (gateway.auth.mode: "token" + gateway.auth.token), then restart.

You’re probing the “wrong” instance/config

Service vs CLI config mismatch (different user / profile / state dir) can have you looking at logs from one run while tunneling to a different place.
openclaw gateway status is the quickest way to spot this because it shows the probe target + config path (and “Config (cli)” vs “Config (service)” when they differ). Docs: https://docs.openclaw.ai/help/faq#gateway-ports-already-running-and-remote-mode

If you paste just:

openclaw --version
openclaw gateway status (full output)

#

…I can tell you which of the two it is and what exact knob to turn.

lavish pendant Mar 8, 2026, 10:09 PM

#

2026.3.7
root@ubuntu-4gb-nbg1-2-openclaw:~# openclaw gateway status

🦞 OpenClaw 2026.3.7 (42a1394) — I'll refactor your busywork like it owes me money.

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is │
│ empty — all group messages will be silently dropped. Add sender IDs to │
│ channels.telegram.groupAllowFrom or channels.telegram.allowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-08.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state activating, sub auto-restart, last exit 0, reason 1)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-03-08.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Troubles: run openclaw status

lone ploverBOT Mar 8, 2026, 10:12 PM

#

Nice, that output is the smoking gun: this isn’t “port is blocked” — your gateway process isn’t staying up, so anything trying to connect (SSH tunnel / Control UI) will intermittently get connection refused.

Key lines:

Runtime: stopped (state activating, sub auto-restart …) → systemd is trying to start it, but it’s exiting/crash-looping
RPC probe: failed … gateway closed (1006 abnormal closure) → the CLI can reach something briefly, then the process disappears mid-connection
the earlier channel 3: open failed … Connection refused is consistent with “tunnel tried to connect while the service was down”

Next: we need the service stderr (systemd/journal), not the JSON file log

The /tmp/openclaw/openclaw-*.log file often won’t include fatal Node exceptions (those go to stderr → journal).

Run these on the VPS and paste output:

# 1) systemd user-unit logs (most important)
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

#


# 2) also paste the end of the file log (in case it did log a fatal)
tail -n 200 /tmp/openclaw/openclaw-2026-03-08.log

If the journal shows something like “requires Node >= 22” or a stack trace, we’ll know immediately what to fix.

Two quick “common cause” checks while you’re there:

/usr/bin/node -v
openclaw config validate

Docs reference for this exact situation: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-say-runtime-running-but-rpc-probe-failed

#

Those journal lines change the story a lot: the gateway is not crashing — it’s being told to stop.

You’ve got:

signal SIGTERM received → something sent the gateway a SIGTERM
then systemd does what the unit file says (Restart=always, RestartSec=5) → restart loop (restart counter is at 170)

So the “connection refused” / SSH channel 3 message is just a symptom of the gateway constantly getting terminated and coming back.

What to do next (fastest isolation)

Stop the systemd service

openclaw gateway stop

Run it in the foreground (no systemd involved), and see if it still gets SIGTERM:

#

openclaw gateway run --verbose

If it stays up in the foreground → something in your systemd/service world (or another process) is repeatedly restarting/stopping it.
If it still gets SIGTERM in the foreground → something external is literally killing it (common culprits: another openclaw gateway --force, a watchdog script, a cron, or a second gateway/service instance).

Two concrete checks that usually reveal the culprit

In another shell while it’s happening:

# See if there are multiple gateway processes/services fighting each other
ps aux | grep -E "openclaw|dist/index.js gateway" | grep -v grep

# See systemd’s view + recent “who/why stopped it” messages
systemctl --user status openclaw-gateway.service --no-pager

#

If you paste the outputs of those two (especially systemctl --user status …), we can pin down whether this is:

a second gateway instance (often started with --force) killing the service, or
an external restart loop (cron/automation), or
a unit/service config issue.

#

Yep — that last bit basically confirms what’s happening:

[restart] killing 1 stale gateway process(es) before restart: 1805167
[gateway] service-mode: cleared 1 stale gateway pid(s) before bind on port 18789

That means: when the systemd-managed gateway starts, it finds another OpenClaw gateway already listening on 18789, treats it as “stale”, and kills it so it can bind the port.

So you almost certainly have two different things starting a gateway (common causes: a second systemd unit/profile, a tmux/screen “openclaw gateway” you started manually, docker compose, or a script using openclaw gateway --force).

Fast way to prove it (and find the culprit)

Stop the systemd service:

openclaw gateway stop

#

Check who is STILL listening on 18789 (there should be nobody):

lsof -nP -iTCP:18789 -sTCP:LISTEN
# or:
ss -lntp | grep 18789

If you see a PID/command there, that’s the other gateway/supervisor you need to stop.

Also run this to detect multiple services:

openclaw gateway status --deep

Once only one gateway instance remains, the “connection refused” + SSH channel 3… spam should disappear.

Docs for the underlying concept (multiple instances / profiles): https://docs.openclaw.ai/gateway/multiple-gateways

#

From that last chunk, the gateway is successfully up now:

listening on ws://127.0.0.1:18789 … (PID 1805205)
webchat connected … client=openclaw-control-ui

So at 22:14:00 the Control UI could connect locally, which means the service is no longer in the “immediate restart / refused” state.

What was happening earlier (and why you saw the SSH channel 3 … connection refused) is consistent with the other log you pasted before:

OpenClaw was detecting a PID already bound to 18789 and doing stale PID cleanup ([restart] killing … stale gateway process / service-mode: cleared … before bind)
i.e. there was another gateway process (manual run / second service / --force run) fighting for the same port, causing brief windows where the tunnel hit a dead port.

If you want to be 100% sure it won’t recur, do this once while it’s “healthy”:

openclaw gateway status --deep

#

lsof -nP -iTCP:18789 -sTCP:LISTEN

You should see exactly one OpenClaw listener for 18789, and --deep shouldn’t show another gateway/service/profile.

Are you still seeing “connection refused” right now, or was that only during the restart fight? If it’s still happening, paste the two command outputs above and we can point to the exact duplicate launcher.

#

That output is actually the clean answer:

You already have a supervised gateway running (systemd) on 127.0.0.1:18789:
- gateway already running (pid 1806854)
- Port 18789 is already in use

So when you try openclaw gateway run --verbose, you’re attempting to start a second gateway on the same port → it refuses to start (lock timeout).

What to do

Pick one mode:

A) Keep the systemd service (recommended on a VPS)

Don’t run openclaw gateway run.
Use:
```
openclaw gateway status
```

#

  openclaw logs --follow

If you’re connecting from your laptop: remember you’re on bind=loopback, so you must use SSH tunnel (or switch bind modes). The SSH channel 3 … connection refused happens when the service is down/restarting at the moment the tunnel tries to connect.

B) Debug in the foreground

Stop the service first:

openclaw gateway stop
openclaw gateway run --verbose

Once you stop trying to run two gateways at once, the “connection refused” noise should go away.

If your actual goal is “access the dashboard from another machine without SSH”, say so and I’ll point you at the right bind option (tailnet/lan) + auth setup.

#

That status --deep output is the “weird but important” case:

systemd says the service is dead: Runtime: stopped (state inactive, sub dead …)
but the port is definitely in use and the gateway answers RPC: Listening: 127.0.0.1:18789 + RPC probe: ok

That means: a gateway is running, but it’s NOT the systemd-managed one (it was started some other way — tmux/screen, a different supervisor, a leftover manual run, etc.).

Next step: identify the process that’s actually listening

Run:

lsof -nP -iTCP:18789 -sTCP:LISTEN
ps -fp <PID_YOU_SEE>

Then pick one “source of truth”

If you want systemd to own it (recommended on a VPS):

#

Stop the systemd unit (even if it claims it’s stopped):

openclaw gateway stop

Stop the other listener (the PID from lsof)
Start the service cleanly:

openclaw gateway start
openclaw gateway status

If you want to run it manually: uninstall/disable the systemd unit so it doesn’t keep confusing things:

openclaw gateway uninstall

Paste the lsof … output (just the lines it prints) and I’ll tell you exactly which one it is and the safest way to shut it down.

lavish pendant Mar 9, 2026, 3:06 PM

#

Is there any problem over here.
root@ubuntu-4gb-nbg1-2-openclaw:~# openclaw gateway status

🦞 OpenClaw 2026.3.7 (42a1394) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is │
│ empty — all group messages will be silently dropped. Add sender IDs to │
│ channels.telegram.groupAllowFrom or channels.telegram.allowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 1)
RPC probe: ok

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

lone ploverBOT Mar 9, 2026, 3:07 PM

#

Yes — there’s one real red flag in that output:

Runtime: stopped (systemd unit is dead)
but RPC probe: ok + Listening: 127.0.0.1:18789 (a gateway is clearly running and answering)

That combination almost always means:

The Gateway is running, but NOT under the systemd service (it was started some other way), so systemd can’t manage/restart it.

So it may “work right now”, but it’s a brittle setup (after a reboot/logout it may vanish, and it can also lead to the “two gateways fighting” situation you hit earlier).

What I’d do to make it clean/stable

Identify what’s actually listening:

lsof -nP -iTCP:18789 -sTCP:LISTEN
# or

#

ss -lntp | grep 18789

If that listener is not systemd’s openclaw unit, stop it and then start the service:

openclaw gateway start
openclaw gateway status

If you paste the lsof (or ss) output line(s), I can tell you exactly what’s holding the port and what to stop.

Unrelated but real: the Doctor warning about channels.telegram.groupPolicy just means Telegram group messages will be dropped until you fill channels.telegram.groupAllowFrom / allowFrom (DMs can still be fine).

lavish pendant Mar 9, 2026, 3:10 PM

#

root@ubuntu-4gb-nbg1-2-openclaw:~# lsof -nP -iTCP:18789 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 1806854 root 22u IPv4 12592232 0t0 TCP 127.0.0.1:18789 (LISTEN)
openclaw- 1806854 root 23u IPv6 12592233 0t0 TCP [::1]:18789 (LISTEN)

lone ploverBOT Mar 9, 2026, 3:11 PM

#

Perfect — that confirms the diagnosis:

PID 1806854 is an OpenClaw gateway process listening on 127.0.0.1:18789
but your openclaw gateway status is still showing the systemd unit as inactive/dead

So right now you have a running gateway that is not (or no longer) tracked by that user systemd service. That’s why you get the confusing “Runtime: stopped” + “RPC probe: ok”.

Next check (to know what to stop/start)

Run:

ps -p 1806854 -o pid,ppid,etimes,cmd
systemctl --user status openclaw-gateway.service --no-pager

If `systemctl --user status …` does NOT show `Main PID: 1806854`

Then 1806854 is effectively an orphan/manual gateway. If you want a clean VPS setup where systemd owns it:

#

Stop the orphan:

kill 1806854

Start the systemd service:

openclaw gateway start
openclaw gateway status

After that, gateway status should show Runtime: running and the PID should match what lsof shows.

(And yep: bind=loopback is fine; it just means you must use SSH tunnel / tailscale serve for remote access.)

lavish pendant Mar 9, 2026, 3:15 PM

#

PID PPID ELAPSED CMD
1806854 1 60896 openclaw-gateway
○ openclaw-gateway.service - OpenClaw Gateway (v2026.3.7)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: inactive (dead) since Sun 2026-03-08 22:20:10 UTC; 16h ago
Duration: 7.721s
Process: 1806793 ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (code=exited, status=0/SUCCESS)
Main PID: 1806793 (code=exited, status=0/SUCCESS)
CPU: 8.203s

Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.738+00:00 [gateway] signal SIGTERM received
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.741+00:00 [gateway] received SIGTERM; shutting down
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.747+00:00 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /ro…claw/canvas)
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.835+00:00 [heartbeat] started
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.846+00:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.853+00:00 [gateway] agent model: openai-codex/gpt-5.4
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.857+00:00 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 1806793)
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw node[1806793]: 2026-03-08T22:20:10.861+00:00 [gateway] log file: /tmp/openclaw/openclaw-2026-03-08.log
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw systemd[783133]: Stopped openclaw-gateway.service - OpenClaw Gateway (v2026.3.7).
Mar 08 22:20:10 ubuntu-4gb-nbg1-2-openclaw systemd[783133]: openclaw-gateway.service: Consumed 8.203s CPU time.
Hint: Some lines were ellipsized, use -l to show in full.

lone ploverBOT Mar 9, 2026, 3:16 PM

#

Yeah — this is the exact “split-brain” state we were circling:

The systemd user service ran as PID 1806793 and then got a SIGTERM and stopped at 22:20:10.
The thing that’s actually listening now is PID 1806854, and it’s PPID 1:

1806854  PPID 1  …  openclaw-gateway

PPID 1 means it’s not being managed by systemd (it’s basically an orphan/daemonized process). That’s why openclaw gateway status says “service dead” but “RPC probe ok”.

Is it “a problem”?

It can “work”, but it’s a problem operationally because:

openclaw gateway stop/start/restart won’t reliably control the running process
after reboot/logout you’ll get unpredictable behavior again
it’s exactly the setup that leads to those port conflicts / SSH “connection refused” moments

#

Clean fix (recommended)

Stop the orphan:

kill 1806854

Start the systemd service again:

openclaw gateway start
openclaw gateway status

After that, systemctl --user status openclaw-gateway.service should show Active: active (running) and the Main PID should match what lsof shows on 18789.

If it keeps stopping when you log out

That’s usually “user service without lingering”. Enable lingering so the user service stays up:

#

loginctl enable-linger root

(Or better: run OpenClaw under a non-root user and enable linger for that user.)

If you want, paste tr '\0' ' ' </proc/1806854/cmdline before killing it — that’ll tell us what started the orphan in the first place.

lavish pendant Mar 9, 2026, 3:23 PM

#

OpenClaw works very slowly, and it doesn’t seem to respond to my commands properly. I often have to repeat myself several times. Do you think this could be caused by this problem?

lone ploverBOT Mar 9, 2026, 3:24 PM

#

It can contribute, but it’s probably not the whole story.

1) “Gateway service dead but something is listening” → reliability issues (missed / repeated messages)

That mismatch (orphan openclaw-gateway not managed by systemd) mainly causes stability problems:

the gateway can get stopped/restarted unexpectedly
connections drop
a message lands while it’s down → you experience “I have to repeat myself”

So yes: I’d fix that first (get to a clean state where systemd says active (running) and the PID matches what lsof shows).

2) The Doctor warning you keep seeing is a direct explanation for “it ignores me”

You have:

channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is empty — all group messages will be silently dropped

If you’re talking to the bot in a Telegram group, it will literally drop every message (so you’ll repeat yourself forever and nothing happens).

#

Fix: add your numeric Telegram user id to channels.telegram.groupAllowFrom (and/or channels.telegram.allowFrom) or set groupPolicy: "open" if that’s what you want. FAQ: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom

3) “Slow” responses are usually model/queue, not gateway bind/service

Once stability + allowlists are correct, if it’s still slow:

check openclaw logs --follow when you send a message (is it waiting on the model / rate-limited / stuck “processing”?)
if you’re sending multiple messages quickly, queue mode can make it feel like it’s ignoring you (default “collect” batches). Try /queue followup in-chat.

If you tell me where you’re issuing commands (Telegram DM vs Telegram group vs Control UI), I can point at the exact config line(s) to change.

lavish pendant Mar 9, 2026, 3:35 PM

#

I've killed 1806854 end start the gateway

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1962949, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@ubuntu-4gb-nbg1-2-openclaw:~# openclaw gateway status

lone ploverBOT Mar 9, 2026, 3:36 PM

#

Good — that’s the “healthy” state you want to see:

Runtime: running (pid 1962949 …)
RPC probe: ok
Listening: 127.0.0.1:18789

So the earlier weirdness (service dead + orphan listener) is fixed, and this should eliminate the random “connection refused / have to repeat myself because the gateway is down” behavior.

Two follow-ups to make this solid:

If you want it to keep running after you logout / reboot (VPS): make sure lingering is enabled for the user running the service (you’re root here):

loginctl enable-linger root

If you’re using Telegram groups: you probably still need to fix that Doctor warning about channels.telegram.groupPolicy + empty allowlist, otherwise group messages will be silently dropped (which feels like “it ignores me”).

#

Now that the gateway is stable, if it still feels slow, run:

openclaw logs --follow

send one message, and paste the 10–20 log lines around it — we can tell whether it’s model latency, queueing, or something else.

If this fixed the “connection refused” part, please mark the solution message in the thread so it gets indexed.

lavish pendant Mar 9, 2026, 3:37 PM

#

1 min later
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state activating, sub auto-restart, last exit 0, reason 1)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Troubles: run openclaw status

lone ploverBOT Mar 9, 2026, 3:38 PM

#

Yeah, that’s not normal — it means the gateway came up, then exited again, and systemd is now in a restart loop:

state activating, sub auto-restart
RPC probe: failed … 1006 abnormal closure

At this point we have to look at why it’s exiting (it’s almost always in the journal as either a SIGTERM, an exception, or an OOM kill).

Please run these and paste the output

# 1) systemd logs for the service (most important)
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

# 2) tail the file log around the same time (sometimes has more context)
tail -n 200 /tmp/openclaw/openclaw-2026-03-09.log

# 3) confirm what (if anything) is currently bound to 18789

#

lsof -nP -iTCP:18789 -sTCP:LISTEN

What I’m expecting we’ll see

If the journal shows “signal SIGTERM received” again → something is stopping it (common: SSH session/user-manager behavior if lingering isn’t enabled, or another watchdog/script calling restart).
If it shows a stack trace / config error → we fix that config.
If it shows OOMKilled → the VPS is running out of RAM and systemd/kernel is killing Node.

Once you paste those three, we can tell which bucket you’re in and the exact fix.

lavish pendant Mar 9, 2026, 3:44 PM

#

Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.110+00:00 [heartbeat] started
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.120+00:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.126+00:00 [gateway] agent model: openai-codex/gpt-5.4
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.129+00:00 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 1967799)
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.141+00:00 [gateway] log file: /tmp/openclaw/openclaw-2026-03-09.log
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.194+00:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.516+00:00 [telegram] [default] starting provider (@tufan_clawbot)
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.531+00:00 [telegram] autoSelectFamily=true (default-node22)
Mar 09 15:43:40 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:40.533+00:00 [telegram] dnsResultOrder=ipv4first (default-node22)
Mar 09 15:43:44 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:44.716+00:00 [gateway] signal SIGTERM received
Mar 09 15:43:44 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:44.719+00:00 [gateway] received SIGTERM; shutting down
Mar 09 15:43:44 ubuntu-4gb-nbg1-2-openclaw node[1967799]: 2026-03-09T15:43:44.763+00:00 [gmail-watcher] gmail watcher stopped
44 ubuntu-4gb-nbg1-2-openclaw systemd[783133]: openclaw-gateway.service: Consumed 9.063s CPU time.
bg1-2-openclaw systemd[783133]: openclaw-gateway.service: Scheduled restart job, restart counter is at 65.
openclaw systemd[783133]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.3.7).

#

{"0":"{"subsystem":"gateway"}","1":"signal SIGTERM received","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-03-09T15:44:45.806Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js:431:14","fileName":"subsystem-C9Xgeyrw.js","fileNameWithLine":"subsystem-C9Xgeyrw.js:431","fileColumn":"14","fileLine":"431","filePath":"usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js","filePathWithLine":"usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js:431","method":"logToFile"}},"time":"2026-03-09T15:44:45.807+00:00"}
{"0":"{"subsystem":"gateway"}","1":"received SIGTERM; shutting down","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-03-09T15:44:45.809Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js:431:14","fileName":"subsystem-C9Xgeyrw.js","fileNameWithLine":"subsystem-C9Xgeyrw.js:431","fileColumn":"14","fileLine":"431","filePath":"usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js","filePathWithLine":"usr/lib/node_modules/openclaw/dist/subsystem-C9Xgeyrw.js:431","method":"logToFile"}},"time":"2026-03-09T15:44:45.810+00:00"}
{"0":"{"subsystem":"gmail-watcher"}","1":"gmail watcher stopped","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gmail-watcher"}","parentNames":["openclaw"],"date":"2026-03-09T15:44:45.853Z","logLevelId":3,"logLevelName":"INFO","path":
{"0":"{"subsystem":"gateway"}","1":"service-mode: cleared 1 stale gateway pid(s) before bind on port 18789","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-03-

#

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 1968303 root 22u IPv4 13586844 0t0 TCP 127.0.0.1:18789 (LISTEN)
openclaw- 1968303 root 23u IPv6 13586845 0t0 TCP [::1]:18789 (LISTEN)

lone ploverBOT Mar 9, 2026, 3:46 PM

#

That log is super useful: the gateway is getting a SIGTERM ~4 seconds after startup:

15:43:40 … listening … (PID 1967799)
15:43:44 … signal SIGTERM received
…
Scheduled restart job, restart counter is at 65.
Started openclaw-gateway.service …

A gateway doesn’t randomly SIGTERM itself — this basically means something else is stopping/restarting it (most commonly: a second OpenClaw gateway/service fighting for the same port, or a system-level unit in addition to the user unit).

Next step: check if you have TWO services/instances

Run these and paste output:

#

# user services (what openclaw gateway status is reporting)
systemctl --user list-units | grep -i openclaw || true
systemctl --user list-unit-files | grep -i openclaw || true

# system services (often the hidden “second one”)
systemctl list-units | grep -i openclaw || true
systemctl list-unit-files | grep -i openclaw || true

# what processes exist right now
ps aux | grep -i openclaw | grep -v grep

Also, grab the system journal around the stop (not just --user), because if a system unit is killing it you’ll see systemd[1] entries:

#

journalctl -n 200 --no-pager | grep -i openclaw

Once we see whether there’s a second openclaw-gateway unit (system-level vs user-level, or another profile), we can tell you exactly which one to disable so the SIGTERM loop stops.

#

That snippet basically confirms the loop mechanism:

One gateway instance is up
then it gets SIGTERM
then the next start logs:

service-mode: cleared 1 stale gateway pid(s) before bind on port 18789

That “cleared stale pid(s)” line only happens when a new gateway process starts and decides someone else is already listening on 18789, so it kills it as “stale”. In other words:

You still have more than one launcher trying to run a gateway on the same port.

Fastest way to pinpoint who owns the listener (systemd vs orphan)

When it’s “up” (even briefly), run:

#

PID="$(lsof -t -iTCP:18789 -sTCP:LISTEN | head -1)"
echo "PID=$PID"
ps -p "$PID" -o pid,ppid,cmd
cat /proc/"$PID"/cgroup

If /proc/<pid>/cgroup contains openclaw-gateway.service → that listener is the systemd unit.
If it doesn’t → it’s an orphan/manual/other-supervisor process that keeps coming back.

Then we need to find the second service/supervisor

Please paste outputs of:

systemctl --user list-units | grep -i openclaw || true
systemctl list-units | grep -i openclaw || true

#

ps aux | grep -i openclaw | grep -v grep

Once we see the “other” unit/process, the fix is simply: stop/disable the duplicate so only one gateway can ever start on 18789.

#

Good — so right now PID 1968303 is the listener on 18789.

Next we need to answer one question: is 1968303 owned by systemd, or is it another orphan/manual process? That will tell us what’s killing what.

Run these and paste the output:

ps -p 1968303 -o pid,ppid,etimes,cmd
cat /proc/1968303/cgroup

Also (to catch the classic “system service + user service both installed” case):

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

#

If /proc/1968303/cgroup contains openclaw-gateway.service, then systemd owns it and something else is restarting/stopping the unit.
If PPID is 1 and cgroup does not mention the unit, it’s an orphan again (and the systemd unit is probably repeatedly starting, killing it as “stale”, then exiting).

Once you paste those, we can tell exactly which duplicate launcher to disable.

lavish pendant Mar 9, 2026, 3:53 PM

#

The unit file looks normal and loginctl show-user root confirms Linger=yes, so this does not appear to be caused by logout/session teardown. The gateway still starts successfully, binds to the port, and then receives SIGTERM a few seconds later. Since the journal also shows OpenClaw killing stale gateway processes before restart, it now looks more like an internal service-mode / stale-process cleanup conflict than a basic systemd configuration issue.

lone ploverBOT Mar 9, 2026, 3:54 PM

#

Your read is basically right on the “linger/logout” part: if Linger=yes and the unit file is sane, this isn’t classic session teardown.

One key clarification though:

The “service-mode: cleared X stale gateway pid(s)” logic only runs when a new gateway process starts.
So if your currently-running gateway gets SIGTERM a few seconds after boot, and you also see “cleared stale pid(s)”, that strongly implies:

something is repeatedly starting another gateway instance, and that new instance is killing the existing listener on :18789 as “stale”.

So it’s still (almost certainly) a multiple-launcher / multiple-service situation — not systemd randomly murdering it.

The fastest way to prove who owns the listener

When it’s up (even briefly), grab the PID and check its cgroup:

PID="$(lsof -t -iTCP:18789 -sTCP:LISTEN | head -1)"

#

ps -p "$PID" -o pid,ppid,etimes,cmd
cat /proc/"$PID"/cgroup

If the cgroup mentions openclaw-gateway.service → systemd owns it.
If PPID is 1 and cgroup doesn’t mention the unit → it’s an orphan/other supervisor.

Then: list all OpenClaw units (user + system)

systemctl --user list-unit-files | grep -i openclaw || true
systemctl list-unit-files | grep -i openclaw || true

If you paste those outputs (plus the cgroup output), we can point at the exact “second launcher” to disable.

Quick workaround if you just need it stable now

#

Move the gateway to a different port so it stops fighting whatever keeps grabbing 18789:

openclaw gateway stop
openclaw gateway install --force --port 18790
openclaw gateway start

(Then your dashboard becomes http://127.0.0.1:18790/ and any tunnels/config need to match.)

If, after we confirm you truly only have one unit and it still restarts, that’s when it’s worth filing a GitHub issue with the journal snippet + your unit file.

lavish pendant Mar 9, 2026, 4:11 PM

#

root@ubuntu-4gb-nbg1-2-openclaw:~# openclaw gateway status

🦞 OpenClaw 2026.3.7 (42a1394) — Alexa, but with taste.

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is │
│ empty — all group messages will be silently dropped. Add sender IDs to │
│ channels.telegram.groupAllowFrom or channels.telegram.allowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18790
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18790

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18790 (service args)
Probe target: ws://127.0.0.1:18790
Dashboard: http://127.0.0.1:18790/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1973932, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18790
Note: CLI config resolves gateway port=18789 (busy).
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@ubuntu-4gb-nbg1-2-openclaw:~#

lone ploverBOT Mar 9, 2026, 4:12 PM

#

Nice — moving the service to 18790 worked, and the gateway is now stable:

Runtime: running …
Listening: 127.0.0.1:18790
RPC probe: ok

But this line is important:

Note: CLI config resolves gateway port=18789 (busy).

That means you now have two separate issues:

Your config still says 18789, so some CLI commands / clients will keep trying :18789.
Something is still listening on 18789 (almost certainly the “other” gateway instance that was causing the stale-PID kill loop).

Next steps (to make it fully clean)

A) Align config to the new port

#

openclaw config set gateway.port 18790

B) Identify and kill the rogue listener on 18789

lsof -nP -iTCP:18789 -sTCP:LISTEN
ps -p <that_pid> -o pid,ppid,etimes,cmd

If you paste the lsof output for :18789, we can tell you exactly what it is and what to disable so it doesn’t come back.

(And separately: your Telegram Doctor warning is still active — group messages will be dropped until you fill channels.telegram.groupAllowFrom/allowFrom or set groupPolicy: "open".)

lavish pendant Mar 9, 2026, 4:52 PM

#

Yes — both ports are currently listening at the same time. 18789 is held by PID 1973762 and 18790 is held by PID 1976273. So there are definitely two separate OpenClaw gateway listeners running concurrently on the same machine.

root@ubuntu-4gb-nbg1-2-openclaw:~# lsof -nP -iTCP:18789 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 1973762 root 22u IPv4 13638447 0t0 TCP 127.0.0.1:18789 (LISTEN)
openclaw- 1973762 root 23u IPv6 13638448 0t0 TCP [::1]:18789 (LISTEN)
root@ubuntu-4gb-nbg1-2-openclaw:~# lsof -nP -iTCP:18790 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 1976273 root 22u IPv4 13656415 0t0 TCP 127.0.0.1:18790 (LISTEN)
openclaw- 1976273 root 23u IPv6 13656416 0t0 TCP [::1]:18790 (LISTEN)

lone ploverBOT Mar 9, 2026, 4:53 PM

#

Yep — that’s now unambiguous: you have two separate gateway processes running at once:

1973762 listening on 18789
1976273 listening on 18790

That’s exactly the kind of setup that can cause the “stale PID cleanup” / SIGTERM churn (one instance starts, decides the other is “stale”, kills it, repeat).

Next: identify which one is systemd-managed (and what’s launching the other)

Run these four commands and paste output:

# show full command lines + parent
ps -p 1973762 -o pid,ppid,etimes,cmd
ps -p 1976273 -o pid,ppid,etimes,cmd

# map PIDs to systemd units (works if they’re inside a unit cgroup)

#

systemctl --user status 1973762 --no-pager -l || true
systemctl --user status 1976273 --no-pager -l || true
systemctl status 1973762 --no-pager -l || true
systemctl status 1976273 --no-pager -l || true

What we’re looking for:

If 1976273 maps to openclaw-gateway.service, keep that one.
Whatever unit (or “no unit”) owns 1973762 is the thing to stop/disable so it doesn’t come back.

Likely end state (what you want)

Only one listener remains (preferably the systemd one on 18790 since that’s what you installed)
Config is aligned too:

#

  openclaw config set gateway.port 18790

Once you paste the PID→unit mapping, I’ll tell you the exact systemctl stop/disable … line to remove the second launcher cleanly.

lavish pendant Mar 9, 2026, 5:04 PM

#

We found the exact cause. There are two separate systemd units running at the same time: a system-level unit at /etc/systemd/system/openclaw-gateway.service holding port 18789, and a user-level unit at ~/.config/systemd/user/openclaw-gateway.service holding port 18790. That explains both the stale PID/SIGTERM churn and the Telegram 409 getUpdates conflict. I’m going to disable and remove the old system-level unit and keep only the user-level service on 18790, then align the CLI config to port 18790 as well.

PID    PPID ELAPSED CMD

1973762 1 3325 openclaw-gateway
PID PPID ELAPSED CMD
1976273 783133 2597 openclaw-gateway
root@ubuntu-4gb-nbg1-2-openclaw:~#

#

Failed to get unit for PID 1973762: PID 1973762 does not belong to any loaded unit.
● openclaw-gateway.service - OpenClaw Gateway (v2026.3.7)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-03-09 16:17:38 UTC; 42min ago
Main PID: 1976273 (openclaw-gatewa)
Tasks: 11 (limit: 4481)
Memory: 410.8M (peak: 793.4M)
CPU: 1min 1.854s
CGroup: /user.slice/user-0.slice/user@0.service/app.slice/openclaw-gateway.service
└─1976273 openclaw-gateway

Mar 09 16:57:56 ubuntu-4gb-nbg1-2-openclaw node[1976273]: 2026-03-09T16:57:56.971+00:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 30s.
Mar 09 16:58:57 ubuntu-4gb-nbg1-2-openclaw node[1976273]: 2026-03-09T16:58:57.467+00:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 30s.
● openclaw-gateway.service - OpenClaw Gateway (v2026.3.1)
Loaded: loaded (/etc/systemd/system/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-03-09 16:05:30 UTC; 54min ago
Main PID: 1973762 (openclaw-gatewa)
Tasks: 49 (limit: 4481)
Memory: 1.3G (peak: 2.4G)
CPU: 50.481s
CGroup: /system.slice/openclaw-gateway.service
├─1811110 sh -c "dotnet run --no-build --urls http://0.0.0.0:5110 >> /root/.openclaw/workspace/logs/backend-api.log 2>&1"
├─1811111 dotnet run --no-build --urls http://0.0.0.0:5110
├─1811132 /root/.openclaw/workspace/WictionaryBackend/src/Api/bin/Debug/net10.0/Api --urls http://0.0.0.0:5110
└─1973762 openclaw-gateway

#

Mar 09 16:58:27 ubuntu-4gb-nbg1-2-openclaw node[1973762]: 2026-03-09T16:58:27.231+00:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 30s.
Mar 09 16:59:27 ubuntu-4gb-nbg1-2-openclaw node[1973762]: 2026-03-09T16:59:27.718+00:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 30s.
● user@0.service - User Manager for UID 0
Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
Drop-In: /usr/lib/systemd/system/user@0.service.d
└─10-login-barrier.conf
/usr/lib/systemd/system/user@.service.d
└─timeout.conf
Active: active (running) since Thu 2026-03-05 19:26:44 UTC; 3 days ago
Docs: man:user@.service(5)
Main PID: 783133 (systemd)
Status: "Ready."
Tasks: 15
Memory: 523.2M (peak: 2.7G)
CPU: 7h 28min 43.755s
CGroup: /user.slice/user-0.slice/user@0.service
├─app.slice
│ ├─gpg-agent.service
│ │ └─786686 /usr/bin/gpg-agent --supervised
│ └─openclaw-gateway.service
│ └─1976273 openclaw-gateway
└─init.scope
├─783133 /usr/lib/systemd/systemd --user
└─783135 "(sd-pam)"

Mar 09 16:49:53 ubuntu-4gb-nbg1-2-openclaw node[1976273]: 2026-03-09T16:49:53.219+00:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 30s.

lone ploverBOT Mar 9, 2026, 5:05 PM

#

That’s a great catch — and the PPIDs line up perfectly with your conclusion:

1973762 PPID 1 → orphaned, consistent with a system-level service / detached process
1976273 PPID 783133 → sitting under the user systemd manager, consistent with systemctl --user

Keeping only one unit should fix all of the symptoms (SIGTERM “stale PID” churn and Telegram 409 getUpdates conflicts).

Suggested safe cleanup sequence (with a backup instead of hard delete):

# 1) Stop + disable the *system* unit (port 18789)
systemctl stop openclaw-gateway.service
systemctl disable openclaw-gateway.service

# 2) Back up the unit file, then reload systemd
mv /etc/systemd/system/openclaw-gateway.service /etc/systemd/system/openclaw-gateway.service.bak

#

systemctl daemon-reload
systemctl reset-failed

Then verify 18789 is free and only 18790 is listening:

lsof -nP -iTCP:18789 -sTCP:LISTEN || echo "18789 free"
lsof -nP -iTCP:18790 -sTCP:LISTEN

Finally align the CLI config to match the service:

openclaw config set gateway.port 18790

#

openclaw gateway status

After that, you can tackle the remaining Telegram group warning (allowlist empty) separately: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom

If this resolves the thread, please mark the solution message so it’s indexed.

#

That output nails it:

systemctl --user … can’t map PID 1973762 because it’s not a user unit (expected).
systemctl … (system scope) does show it: /etc/systemd/system/openclaw-gateway.service (v2026.3.1) running on PID 1973762.
Your user unit is the v2026.3.7 one on PID 1976273.
The Telegram 409 getUpdates conflict is exactly what you get when both are polling.

Fix: stop + disable the system-level unit (this will also kill those dotnet child processes in its cgroup)

Run:

systemctl disable --now openclaw-gateway.service

# (optional but recommended) move the old unit file out of the way
mv /etc/systemd/system/openclaw-gateway.service /etc/systemd/system/openclaw-gateway.service.bak
systemctl daemon-reload

#

systemctl reset-failed

Then verify you only have the user one:

systemctl status openclaw-gateway.service --no-pager   # should be inactive/not found
systemctl --user status openclaw-gateway.service --no-pager
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo "18789 free"
lsof -nP -iTCP:18790 -sTCP:LISTEN

After that, the Telegram 409 spam should stop within the next retry window (30s).

If you want to keep using port 18790 long-term, also align config so the CLI stops mentioning 18789:

#

openclaw config set gateway.port 18790

#

Those lines still show both processes are polling Telegram:

node[1973762] … getUpdates conflict … (system-level gateway)
node[1976273] … getUpdates conflict … (user-level gateway)

So the fix isn’t “maybe” — the system-level unit is still running right now, and it’s still fighting the user one.

Do this in system scope (no `--user`)

systemctl disable --now openclaw-gateway.service
systemctl status openclaw-gateway.service --no-pager -l
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo "18789 free"

You want systemctl status … to show inactive/dead (or “not found” after you move the unit file + daemon-reload), and 18789 to be free.

Then restart the remaining user gateway (or wait 30s)

#

systemctl --user restart openclaw-gateway.service
# or: openclaw gateway restart

After that, the Telegram 409 getUpdates conflict should stop on the next poll cycle.
If it still continues with only one gateway running, that would mean there’s a third bot instance elsewhere using the same token — but right now you definitely still have two on this box.

lavish pendant Mar 9, 2026, 5:15 PM

#

Looks good now. The system-level unit is gone, only the user-level gateway on port 18790 remains, 18789 is free, and the Telegram 409 getUpdates conflict appears to be gone. The logs now show normal startup and sendMessage ok, so the duplicate-instance issue seems resolved.

lone ploverBOT Mar 9, 2026, 5:16 PM

#

Good — that’s exactly the end state we were aiming for.

Final cleanup/checklist so it stays consistent:

Make config match the running gateway port (so CLI/tools don’t keep “resolving 18789”):

openclaw config set gateway.port 18790

Verify only one listener (optional sanity check):

lsof -nP -iTCP:18789 -sTCP:LISTEN || echo "18789 free"
lsof -nP -iTCP:18790 -sTCP:LISTEN

Telegram group warning (if you care about groups): you’ll still want to set channels.telegram.groupAllowFrom / allowFrom or change groupPolicy, otherwise group messages get dropped. Docs: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom

#

If this thread is solved now, please right-click the solution message → Apps → Mark Solution so Answer Overflow indexes it.

lavish pendant Mar 9, 2026, 5:17 PM

#

root@ubuntu-4gb-nbg1-2-openclaw:~# lsof -nP -iTCP:18789 -sTCP:LISTEN || echo "18789 free"
lsof -nP -iTCP:18790 -sTCP:LISTEN
18789 free
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 1984817 root 22u IPv4 13699431 0t0 TCP 127.0.0.1:18790 (LISTEN)
openclaw- 1984817 root 23u IPv6 13699432 0t0 TCP [::1]:18790 (LISTEN)

lone ploverBOT Mar 9, 2026, 5:17 PM

#

Perfect — that’s clean:

18789 free
exactly one OpenClaw listener on 18790 (PID 1984817)

At this point the duplicate-instance / SIGTERM stale-PID loop should be fully resolved.

If you haven’t already, please mark the solution message in the thread (Apps → Mark Solution) so it’s indexed for others.

lavish pendant Mar 9, 2026, 5:19 PM

#

What should I do to upgrade version.

lone ploverBOT Mar 9, 2026, 5:20 PM

#

If you want to upgrade OpenClaw on that VPS, you’ve got two good options.

Option A (recommended): use the built-in updater

This works for both npm installs and git installs and will handle the restart flow.

openclaw update status
openclaw update

Then verify:

openclaw --version
openclaw gateway status

#

Option B: re-run the website installer (upgrade in place)

This is the “blessed” path and will upgrade + run doctor when needed:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

(omit --no-onboard if you want to re-run the wizard)

If you installed globally and just want a straight package update

npm i -g openclaw@latest
openclaw doctor
openclaw gateway restart

Docs: https://docs.openclaw.ai/install/updating

#Connection refused

Next: we need the service stderr (systemd/journal), not the JSON file log

What to do next (fastest isolation)

Two concrete checks that usually reveal the culprit

Fast way to prove it (and find the culprit)

What to do

Next step: identify the process that’s actually listening

Then pick one “source of truth”

What I’d do to make it clean/stable

Next check (to know what to stop/start)

If systemctl --user status … does NOT show Main PID: 1806854

Is it “a problem”?

Clean fix (recommended)

If it keeps stopping when you log out

1) “Gateway service dead but something is listening” → reliability issues (missed / repeated messages)

2) The Doctor warning you keep seeing is a direct explanation for “it ignores me”

3) “Slow” responses are usually model/queue, not gateway bind/service

Please run these and paste the output

What I’m expecting we’ll see

Next step: check if you have TWO services/instances

Fastest way to pinpoint who owns the listener (systemd vs orphan)

Then we need to find the second service/supervisor

The fastest way to prove who owns the listener

Then: list all OpenClaw units (user + system)

Quick workaround if you just need it stable now

Next steps (to make it fully clean)

Next: identify which one is systemd-managed (and what’s launching the other)

Likely end state (what you want)

Fix: stop + disable the system-level unit (this will also kill those dotnet child processes in its cgroup)

Do this in system scope (no --user)

Then restart the remaining user gateway (or wait 30s)

Option A (recommended): use the built-in updater

Option B: re-run the website installer (upgrade in place)

If you installed globally and just want a straight package update

If `systemctl --user status …` does NOT show `Main PID: 1806854`

Do this in system scope (no `--user`)