#gateway connect failed: Error: gateway closed (1000)

1 messages · Page 1 of 1 (latest)

tawny tapir
#

@zealous hearth requesting for troubleshooting. my gateway keeps restart whenever i give a prompt to my agent
openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) —
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /root/.nvm/versions/node/v24.14.0/bin/node /root/.nvm/versions/node/v24.14.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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. (/root/.nvm/versions/node/v24.14.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/root/.nvm/versions/node/v24.14.0/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 8271, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: *:18789

zealous hearthBOT
#

That status is healthy at idle, so the useful clue will be the log line right when the prompt triggers the restart.

Two things jump out:

  1. Your service is pinned to nvm Node: /root/.nvm/versions/node/v24.14.0/...
  2. OpenClaw is explicitly warning the service config is out of date/non-standard.

I’d do this first:

openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

If it still warns about nvm/version-manager Node, install a system Node 24 and rerun doctor --repair. Docs: https://docs.openclaw.ai/install/node and https://docs.openclaw.ai/gateway/doctor

#

Then reproduce the crash with logs open:

openclaw logs --follow --plain --local-time

Send one prompt to the agent, wait for the restart, then paste the error/stack trace around the crash. Also useful:

journalctl --user -u openclaw-gateway -n 120 --no-pager

Please redact tokens/API keys if any show up. The restart-on-prompt part could be model/provider/plugin related, but the crash log will tell us which one instead of guessing.

tawny tapir
#

@zealous hearth
how can I move the Gateway away from the nvm path to a stable, system-wide Node installation. This prevents the "it works now but breaks after an update" cycle.
which openclaw
/root/.nvm/versions/node/v24.14.0/bin/openclaw
node -v
v24.14.0
/usr/bin/node -v
v24.15.0

tawny tapir
zealous hearthBOT
#

Yep — since /usr/bin/node is already v24.15.0, they mostly need to reinstall the OpenClaw CLI/service from the system Node path, not the nvm one.

Run from SSH/root shell:

/usr/bin/npm install -g openclaw@latest
hash -r

# verify this no longer points into /root/.nvm
which openclaw
openclaw --version

If which openclaw still shows /root/.nvm/..., their PATH is still prioritizing nvm. Either start a shell without nvm loaded, or use the system-installed binary path directly, e.g.:

tawny tapir
#

@zealous hearth how can i correct the version since now openclaw is pointed to right path
which openclaw
openclaw --version
/usr/bin/openclaw
OpenClaw 2026.4.15 (041266a)

openclaw gateway status --deep
Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.15.

🦞 OpenClaw 2026.4.15 (041266a) — Your config is valid, your assumptions are not.

Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.15.
Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.15.


Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.0.81:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

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

Listening: *:18789

zealous hearthBOT
#

Yep — path is fixed, but the installed package is older.

Your config was written by 2026.4.26, but /usr/bin/openclaw is 2026.4.15, so upgrade that global install:

openclaw update

If that doesn’t update cleanly, do the manual npm path:

npm install -g openclaw@latest
hash -r
openclaw --version

Then refresh the systemd service so it uses the updated install:

#
openclaw gateway install --force
openclaw gateway restart
openclaw doctor
openclaw gateway status --deep

You want openclaw --version and openclaw gateway status --deep to show the same/newer version — at least 2026.4.26, not 2026.4.15.

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

tawny tapir
#

@zealous hearth i have checked the logs again

The Current Issue: "Stuck Sessions"

The logs are reporting a stuck session:
message: "stuck session: sessionId=main sessionKey=agent:main:telegram:direct:100...2870 state=processing age=164s queueDepth=1"
how can i resolve the above as my server is restarting

zealous hearthBOT
#

That stuck session line is usually a symptom, not the root cause.

It means this Telegram session has one active agent run stuck in processing for ~164s, and queueDepth=1 means another message is waiting behind it.

Try clearing the active run first from the same Telegram chat:

/stop
/reset

If the gateway is too wedged to receive that:

openclaw gateway restart
#

Then immediately send:

/reset

After that, find the actual restart cause:

openclaw --version
openclaw gateway status --deep
openclaw logs --follow
openclaw gateway stability --bundle latest

Send one prompt, then look for the first real error before the restart — OOM/killed, model timeout, provider error, tool crash, etc. The stuck session warning alone doesn’t explain why systemd is restarting the server.