Discord Channel Dropping | Friends of the Crustacean 🦞🤝 | Page 1

serene cypress Apr 28, 2026, 11:34 PM

#

I'm on 4.26 now after experiencing issues from upgrading to 4.25 yesterday. However, now my agent only briefly connects to Discord, then the connection fails. Some messages have made it through but very inconsistent.

full pollenBOT Apr 28, 2026, 11:34 PM

#

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

fallen trailBOT Apr 28, 2026, 11:34 PM

#

Hmm, for Discord flapping we need the exact disconnect reason from logs.

Please paste:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe

Then run this while it drops and paste the Discord-ish lines around the failure:

openclaw logs --follow

#

Please don’t paste your Discord bot token.

First easy repair after upgrades:

openclaw doctor
openclaw gateway restart

If channels status --probe shows Discord briefly connected then disconnected, the useful bit will usually be a gateway close code / 401, 403, Forbidden, intent/permission error, or reconnect loop in the logs.

Docs for the same triage ladder: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/channels/troubleshooting 🦐

serene cypress Apr 29, 2026, 12:20 AM

#

openclaw@pi:~ $ which openclaw
/usr/local/bin/openclaw
openclaw@pi:~ $ openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
OpenClaw 2026.4.26 (be8c246)

🦞 OpenClaw 2026.4.26 (be8c246) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

fallen trailBOT Apr 29, 2026, 12:20 AM

#

That output only confirms the CLI version — I don’t yet see the status, gateway, or Discord probe output.

Can you run these one at a time and paste the full output?

openclaw status --all
openclaw gateway status --deep
openclaw channels status --probe

Then start logs, restart the gateway, and wait for the Discord drop:

openclaw logs --follow

In another terminal:

#

openclaw gateway restart

The key thing we need is the log line where Discord disconnects/reconnects — especially any close code, 401/403, intent error, Forbidden, or token/permission message. Don’t paste the bot token.

serene cypress Apr 29, 2026, 12:21 AM

#

Item │ Value │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.26 │
│ OS │ linux 6.12.75+rpt-rpi-v8 (arm64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/

#

Tailscale exposure │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.26 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout) │
│ Security │ Run: openclaw security audit --deep │

#

│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 126827, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 1 active · 3 sessions │
│ Secrets │ none

#

Channels
┌──────────┬─────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌────────────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 3 │ 3m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/openclaw/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

fallen trailBOT Apr 29, 2026, 12:22 AM

#

That paste is still only the top of status --all — useful rows are lower down.

Please run/attach these as files so Discord doesn’t mangle the tables:

openclaw status --all > /tmp/oc-status.txt
openclaw gateway status --deep > /tmp/oc-gateway.txt
openclaw channels status --probe > /tmp/oc-channels.txt

And grab the Discord-related log tail:

tail -n 400 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" \
  | grep -Ei 'discord|websocket|carbon|1006|disconnect|closed|reconnect|health-monitor|uncaught|forbidden|401|403|timeout|slow listener'

#

Two things I’d look for:

WebSocket connection closed with code 1006 / Max reconnect attempts / Uncaught exception → gateway/Discord WS crash style issue.
Listener DiscordMessageListener timed out, Slow listener, or discord inbound worker timed out → on a Pi this could be listener pressure; docs list channels.discord.eventQueue.listenerTimeout as the knob for that. (github.com)

Don’t paste the Discord token, but the status files should be redacted.

#

That line is the important bit:

Gateway · ws://127.0.0.1:18789 · unreachable (timeout)

So I’d stop chasing Discord config for the moment — your local Gateway is either not running cleanly, hung, or starting and then wedging. Discord will look flaky as a symptom.

Please run these next:

openclaw gateway status --deep
openclaw doctor
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

#

If it still says unreachable/timeout, grab logs from the failing window:

openclaw logs --follow

or, if that can’t connect:

tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Paste the part around gateway startup/failure. Look especially for EADDRINUSE, uncaught, fatal, out of memory, plugin install/runtime errors, or repeated Discord reconnect messages.

Docs for this exact flow: https://docs.openclaw.ai/help/troubleshooting and https://docs.openclaw.ai/gateway/troubleshooting

#

Yep — this confirms the split: systemd says the gateway process is running, but the gateway RPC/WebSocket is timing out. That usually means the process is hung during startup/runtime, not a simple Discord permission issue.

Next most useful commands:

openclaw gateway status --deep
openclaw doctor
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

If you want a quick recovery attempt before digging deeper:

openclaw gateway restart
sleep 5

#

openclaw gateway status --deep

If it’s still timeout after restart, paste the journalctl + /tmp/openclaw tail. The smoking gun should be there. Since this is on a Raspberry Pi, I’d also check for memory pressure/OOM in the service logs.

#

That empty Channels table is a big clue: the CLI isn’t seeing any enabled channel config at all.

So now we likely have one of these:

Discord config/token didn’t survive the 4.25/4.26 migration/update.
The systemd service is running with a different config/env than the CLI.
An old/stale gateway process is running, but the current CLI config has no Discord channel.

Please run:

openclaw config get channels
openclaw config get channels.discord
openclaw gateway status --deep
systemctl --user cat openclaw-gateway.service
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

#

If channels.discord is empty/missing, re-enable Discord/token config and restart. If it exists there but the Channels table is empty, that points to config/env mismatch between your shell and the systemd service.

Don’t paste the token if it appears — redact it first.

serene cypress Apr 29, 2026, 12:23 AM

#

It's says I'm unable to paste it here, becuase it's markdown and too long

fallen trailBOT Apr 29, 2026, 12:23 AM

#

The Agents table is okay; it just means sessions exist. The blocker is still the earlier combo:

Gateway RPC timing out
Channels table empty

That “empty channel registry despite Discord/Telegram config” has shown up in prior bug reports, so if your config still has Discord enabled this may be regression-ish rather than user setup. (github.com)

Please paste these next, ideally as files/code blocks:

openclaw config get channels.discord
openclaw gateway status --deep
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

If channels.discord is missing/empty → re-enable Discord config.

GitHub

[Bug]: Channels table empty and Telegram/Discord unavailable on Win...

Bug type Regression (worked before, now fails) Beta release blocker No Summary On Windows with OpenClaw 2026.4.2, the gateway is reachable but the active channel registry remains empty, so outbound...

#

If channels.discord.enabled is true but status still shows no channels → run:

openclaw doctor --repair
openclaw gateway restart

…and if it still happens, this is probably worth a GitHub issue with your status --all, gateway logs, OS/RPi info, and version. Redact tokens.

#

Good — config path is consistent now:

/home/openclaw/.openclaw/openclaw.json

But we still need the lower part of gateway status --deep / logs to know why RPC is timing out.

Can you paste the rest after “Restart sentinel: none”, plus:

openclaw config get channels.discord
openclaw config get channels
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

#

The next branch is:

channels.discord missing/disabled → config got reset/migrated; re-enable Discord.
channels.discord.enabled: true but channels table empty + RPC timeout → likely gateway startup/runtime bug; logs are needed.
systemd running but no listener on 127.0.0.1:18789 → service process may be wedged or binding elsewhere.

#

No worries — don’t paste the whole thing. Attach it as .txt, or filter it down.

Try this:

mkdir -p /tmp/oc-debug

openclaw config get channels.discord > /tmp/oc-debug/discord-config.txt 2>&1
openclaw gateway status --deep > /tmp/oc-debug/gateway-deep.txt 2>&1
openclaw channels status --probe > /tmp/oc-debug/channels-probe.txt 2>&1
journalctl --user -u openclaw-gateway.service -n 300 --no-pager > /tmp/oc-debug/journal.txt 2>&1
tail -n 500 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" > /tmp/oc-debug/openclaw-log-tail.txt 2>&1

Then upload those files here.

If Discord still complains, run this smaller filtered version and paste the output:

#

grep -Eina 'discord|gateway|error|fatal|uncaught|timeout|disconnect|closed|reconnect|EADDRINUSE|forbidden|401|403|1006|oom|memory|listener|websocket' /tmp/oc-debug/*.txt | tail -n 200

Please quickly open discord-config.txt first and redact any plaintext token if one appears. SecretRef/env references are fine.

serene cypress Apr 29, 2026, 2:15 AM

#

Gateway last log line:
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
! Port 18789
Port 18789 is already in use.

pid 126827 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 43 eligible · 0 missing · /home/openclaw/.openclaw/workspace
✓ Plugin compatibility (none)

#

Problem:

plugins.entries.openrouter: plugin not found: openrouter
Run: openclaw doctor --fix
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

fallen trailBOT Apr 29, 2026, 2:15 AM

#

That’s the smoking gun: port 18789 is occupied by an openclaw-gateway process, but the CLI can’t manage it via user systemd and earlier RPC was timing out. So it’s likely a wedged/stale gateway, not Discord itself.

Try this reset:

# make user systemd usable on the Pi
sudo loginctl enable-linger openclaw

# log in as the same user that owns OpenClaw
sudo -iu openclaw

openclaw gateway stop
sleep 3
openclaw gateway start
openclaw gateway status --deep
openclaw channels status --probe

#

If gateway stop still can’t reach systemd, stop the stuck PID directly:

kill -TERM 126827
sleep 5
openclaw gateway start
openclaw gateway status --deep

If it wedges again after that, grab the fresh /tmp/openclaw log tail and file it as a GitHub issue: https://github.com/openclaw/openclaw/issues. The useful repro is: Raspberry Pi arm64, OpenClaw 2026.4.26, gateway binds 127.0.0.1:18789 but RPC times out / Discord flaps.

#

Nice, that’s likely the real blocker now.

You have two separate issues:

Stale plugin config

plugins.entries.openrouter: plugin not found: openrouter

Fix that first:

sudo -iu openclaw
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak
openclaw doctor --fix

You’re running commands without the openclaw user systemd session

#

   $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

On the Pi, enable linger and run from the actual openclaw user:

sudo loginctl enable-linger openclaw
sudo -iu openclaw
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

If doctor --fix removes/repairs the stale openrouter plugin entry and the gateway becomes reachable, Discord should stop flapping. If it still times out after that, paste the fresh log tail.

serene cypress Apr 29, 2026, 2:16 AM

#

[2026-03-27T15:24:13-04:00] Starting gateway...
[2026-03-27T15:24:13-04:00] Gateway started with PID: 791
… 2 lines omitted …
Config was last written by a newer OpenClaw (2026.3.25); current version is 2026.2.23.
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
[2026-03-27T17:03:53-04:00] Starting gateway...
[2026-03-27T17:03:53-04:00] Gateway started with PID: 792
[2026-03-27T17:03:53-04:00] Starting gateway...
Config was last written by a newer OpenClaw (2026.3.25); current version is 2026.2.23.
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
Config was last written by a newer OpenClaw (2026.3.25); current version is 2026.2.23.
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

#

[2026-03-27T17:32:02-04:00] Starting gateway...
[2026-03-27T17:32:02-04:00] Gateway started with PID: 792
Config was last written by a newer OpenClaw (2026.3.25); current version is 2026.2.23.
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
Config was last written by a newer OpenClaw (2026.3.25); current version is 2026.2.23.
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

#

! Channel issues skipped (gateway unreachable)

Gateway health:
timeout

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

🦞 OpenClaw 2026.4.26 (be8c246) — Your .zshrc wishes it could do what I do.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /usr/local/bin/openclaw 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: RestartSec does not match the recommended 5s (/home/openclaw/.config/systemd/user/openclaw-gateway.service)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
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.

fallen trailBOT Apr 29, 2026, 2:16 AM

#

That log is from March 27, so it may be stale — but it shows a classic split-brain install:

config written by 2026.3.25; current version is 2026.2.23

Even though your shell now says 2026.4.26, the gateway service may still be launching an old OpenClaw binary.

Please check what systemd is actually running:

sudo loginctl enable-linger openclaw
sudo -iu openclaw

which openclaw
openclaw --version

#

systemctl --user cat openclaw-gateway.service
ps -fp 126827
readlink -f /proc/126827/exe

If systemctl --user cat ... points at an old path/version, reinstall the service from the 4.26 CLI:

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

Then fix the stale plugin entry:

#

openclaw doctor --fix
openclaw gateway restart
openclaw channels status --probe

The goal is: one 2026.4.26 gateway process, reachable on 127.0.0.1:18789, with Discord listed in channels.

serene cypress Apr 29, 2026, 2:16 AM

#

Runtime: running (pid 126827, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 126827 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.26 (be8c246) — If it works, it's automation; if it breaks, it's a "learning opportunity."

│
◇
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /home/openclaw/.openclaw/openclaw.json
Mode: local

fallen trailBOT Apr 29, 2026, 2:16 AM

#

Those are still old March 27 logs from when the service was launching 2026.2.23. Don’t chase those unless the current service still points there.

Run this to inspect the actual current stuck PID:

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

ps -fp 126827
tr '\0' ' ' < /proc/126827/cmdline; echo
readlink -f /proc/126827/cwd
systemctl --user cat openclaw-gateway.service

If that service/cmdline points anywhere stale, reinstall it from current 2026.4.26:

#

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

If restart can’t stop the wedged process:

kill -TERM 126827
sleep 5
openclaw gateway start

Then check the fresh latest log:

#

ls -lt /tmp/openclaw/openclaw-*.log | head
tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Main targets: remove stale plugins.entries.openrouter, fix the user systemd env, and make sure only one 2026.4.26 gateway owns port 18789.

#

Okay, this is now cleanly narrowed:

Current service is 2026.4.26
Config path matches
But gateway health is timeout
Service file is non-standard/out of-date
Channel checks are skipped because the gateway RPC can’t respond

Do this from the openclaw user:

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

openclaw doctor --repair

#

openclaw gateway install --force
openclaw gateway restart
sleep 5
openclaw gateway status --deep

If it still times out, stop the wedged process and start fresh:

openclaw gateway stop
pkill -f 'openclaw gateway'
sleep 5
openclaw gateway start
openclaw gateway status --deep

#

Then immediately check the fresh log:

tail -n 250 /tmp/openclaw/openclaw-2026-04-28.log

Also fix the stale plugin issue you showed earlier if doctor --repair didn’t:

openclaw config get plugins.entries.openrouter

If that still exists and says plugin not found, remove the stale openrouter plugin entry from ~/.openclaw/openclaw.json or let doctor --repair clean it. The gateway needs to become reachable before Discord can be stable.

#

That process is listening but not answering. After 30s, “warm-up” is no longer the likely explanation — PID 126827 is probably wedged.

Do this from the openclaw user:

sudo -iu openclaw
export XDG_RUNTIME_DIR=/run/user/$(id -u)

systemctl --user stop openclaw-gateway.service
sleep 5
ps -fp 126827

If PID 126827 is still there:

#

kill -TERM 126827
sleep 5
ps -fp 126827

Then start it in the foreground once so we can see the real startup blocker:

openclaw gateway --port 18789

If it prints the plugins.entries.openrouter: plugin not found: openrouter error again, run:

openclaw doctor --repair

#

Then reinstall/restart the service:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

Right now Discord is a downstream symptom — the gateway itself is stuck accepting the port but not responding to RPC.

serene cypress Apr 29, 2026, 2:18 AM

#

openclaw@pi:~ $ sudo loginctl enable-linger openclaw
sudo -iu openclaw

which openclaw
openclaw --version
[sudo] password for openclaw:
openclaw@pi:~$ which openclaw
/usr/local/bin/openclaw
openclaw@pi:~$ openclaw --version
OpenClaw 2026.4.26 (be8c246)
openclaw@pi:~$ systemctl --user cat openclaw-gateway.service
ps -fp 126827
readlink -f /proc/126827/exe
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
UID PID PPID C STIME TTY TIME CMD
openclaw 126827 1292 32 19:05 ? 01:02:57 openclaw-gateway
/usr/bin/node

fallen trailBOT Apr 29, 2026, 2:18 AM

#

Good, that confirms the gateway process is not old, but it’s badly wedged:

openclaw-gateway ... CPU 32% ... TIME 01:02:57

Also sudo -iu openclaw isn’t giving you the user systemd bus env. Try this:

UID_NUM=$(id -u openclaw)
sudo loginctl enable-linger openclaw
sudo systemctl start user@${UID_NUM}.service

sudo -iu openclaw
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus

#

systemctl --user cat openclaw-gateway.service

Then stop the wedged gateway:

systemctl --user stop openclaw-gateway.service
sleep 5
ps -fp 126827

If it’s still alive:

kill -TERM 126827

#

sleep 5

Then repair/reinstall/start cleanly:

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

If it wedges again immediately, start foreground once and paste the last ~100 lines:

#

openclaw gateway --port 18789

That high CPU stuck gateway is the thing to clear before Discord can stabilize.

serene cypress Apr 29, 2026, 2:21 AM

#

openclaw@pi:~ $ UID_NUM=$(id -u openclaw)
sudo loginctl enable-linger openclaw
sudo systemctl start user@${UID_NUM}.service

sudo -iu openclaw
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
openclaw@pi:~$ systemctl --user cat openclaw-gateway.service
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
openclaw@pi:~$ systemctl --user stop openclaw-gateway.service
sleep 5
ps -fp 126827
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
UID PID PPID C STIME TTY TIME CMD
openclaw 126827 1292 32 19:05 ? 01:03:02 openclaw-gateway
openclaw@pi:~$ kill -TERM 126827
openclaw@pi:~$ sudo openclaw doctor --repair
sudo openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

#

OpenClaw doctor
│
◇ Startup optimization ─────────────────────────────────────────────────────────────────────╮
│ │
│ - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM). │
│ - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from │
│ self-respawn. │
│ - Suggested env for low-power hosts: │
│ export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache │
│ mkdir -p /var/tmp/openclaw-compile-cache │
│ export OPENCLAW_NO_RESPAWN=1 │
│ │

◇ Plugin registry ────────────────────────────────────────────╮
│ │
│ Plugin registry refreshed: 67/115 enabled plugins indexed. │
│ │
├──────────────────────────────────────────────────────────────╯
.

#

│
◇ State integrity ─────────────────────────────────────────────────────────────────────────╮
│ │
│ - State directory appears to be on SD/eMMC storage (~/.openclaw; device /dev/mmcblk0p2, │
│ fs ext4, mount /). │
│ - SD/eMMC media can be slower for random I/O and wear faster under session/log churn. │
│ - For better startup and state durability, prefer SSD/NVMe (or USB SSD on Raspberry Pi) │
│ for OPENCLAW_STATE_DIR. │
│ - OAuth dir not present (~/.openclaw/credentials). Skipping create because no │
│ WhatsApp/pairing channel config is active. │
│ - Multiple state directories detected. This can split session history. │
│ - /home/openclaw/.openclaw │
│ Active state dir: ~/.openclaw │
│ │

◇ Security ─────────────────────────────────╮
│ │
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │
│ │

◇ Systemd ─────────────────────────────────────────────────────────────────────────╮
│ │
│ Unable to read loginctl linger status. Ensure systemd + loginctl are available

fallen trailBOT Apr 29, 2026, 2:22 AM

#

Careful: don’t run sudo openclaw doctor / sudo openclaw gateway install here. That runs OpenClaw as root and may touch /root/.openclaw or install the wrong service.

If that sudo openclaw ... command is still running, Ctrl-C it.

Then run this from your normal shell:

sudo loginctl enable-linger openclaw
UID_NUM=$(id -u openclaw)
sudo systemctl start user@${UID_NUM}.service

sudo systemctl --machine=openclaw@.host --user stop openclaw-gateway.service || true
sudo kill -TERM 126827 || true
sleep 5
ps -fp 126827 || echo "old wedged gateway stopped"

#

If PID 126827 is still alive:

sudo kill -KILL 126827

Then repair as the openclaw user, not root:

sudo -iu openclaw bash -lc '
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus

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

#

openclaw gateway status --deep
openclaw channels status --probe
'

Your previous systemctl --user failed because the user bus env still wasn’t available in that shell. The --machine=openclaw@.host --user form bypasses that.

#

Good — doctor is actually running now. Let it finish.

If it hangs at the . for more than ~2–3 minutes on the Pi, stop it and do the lower-overhead env it suggested:

Ctrl-C

mkdir -p /var/tmp/openclaw-compile-cache
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1

openclaw doctor --repair

After doctor finishes, restart cleanly:

#

openclaw gateway install --force
openclaw gateway restart
sleep 10
openclaw gateway status --deep
openclaw channels status --probe

Also check whether the old wedged PID died:

ps -fp 126827 || echo "old wedged gateway stopped"

If 126827 is still alive after your kill -TERM, kill it with sudo kill -KILL 126827 before restarting.

serene cypress Apr 29, 2026, 2:22 AM

#

◇ Skills status ────────────╮
│ │
│ Eligible: 14 │
│ Missing requirements: 42 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│
◇ Plugins ──────╮
│ │
│ Loaded: 67 │
│ Imported: 0 │
│ Disabled: 48 │
│ Errors: 0 │
│ │
├────────────────╯
│
◇
│
◇ Gateway ──────────────╮
│ │
│ Gateway not running. │
│ │
├────────────────────────╯
│
◇ Gateway connection ────────────────────╮
│ │
│ Gateway target: ws://127.0.0.1:18789 │
│ Source: local loopback │
│ Config: /root/.openclaw/openclaw.json │
│ Bind: loopback │
│ │
├─────────────────────────────────────────╯
│
◇ Gateway ─────────────────────────────────────────────────────────────────────────╮
│ │
│ Runtime: running (pid 145364, state active, sub running, last exit 0, reason 0) │
│ │
├───────────────────────────────────────────────────────────────────────────────────╯
Restarted systemd service: openclaw-gateway.service

fallen trailBOT Apr 29, 2026, 2:23 AM

#

That output is useful. Combined with the earlier empty Channels table, OpenClaw currently isn’t seeing an active Discord channel config.

Do not use sudo openclaw ... for OpenClaw commands. Only use sudo for loginctl/killing the stuck PID.

# as openclaw user
openclaw config get channels
openclaw config get channels.discord

If Discord is missing/disabled, re-enable it:

export DISCORD_BOT_TOKEN="your-token-here"

#

openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json

For the service to see that env token, put it in:

~/.openclaw/.env

Then:

openclaw doctor --repair
openclaw gateway install --force

#

openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

Goal: channels status --probe should list discord as enabled/connected. Docs: https://docs.openclaw.ai/channels/discord

serene cypress Apr 29, 2026, 2:23 AM

#

🦞 OpenClaw 2026.4.26 (be8c246) — If you can describe it, I can probably automate it—or at least make it funnier.

Installed systemd service: /root/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /root/.config/systemd/user/openclaw-gateway.service.bak

🦞 OpenClaw 2026.4.26 (be8c246) — We ship features faster than Apple ships calculator updates.

Gateway service disabled.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: systemctl --user start openclaw-gateway.service

🦞 OpenClaw 2026.4.26 (be8c246) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /usr/local/bin/openclaw 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: RestartSec does not match the recommended 5s (/home/openclaw/.config/systemd/user/openclaw-gateway.service)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
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: unknown (Failed to connect to system scope bus via machine transport: Permission denied
Failed to get properties: Transport endpoint is not connected)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

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

#

🦞 OpenClaw 2026.4.26 (be8c246) — Your second brain, except this one actually remembers where you left things.

│
◇
Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback

Possible causes:

Gateway not yet ready to accept connections (retry after a moment)
TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
Gateway crashed or was terminated unexpectedly
Run openclaw doctor for diagnostics.
Gateway not reachable; showing config-only status.
Config: /home/openclaw/.openclaw/openclaw.json
Mode: local

fallen trailBOT Apr 29, 2026, 2:23 AM

#

Stop here — this output shows you accidentally ran OpenClaw as root:

Config: /root/.openclaw/openclaw.json

That can start a second/root gateway with no Discord config and steal port 18789.

Run this cleanup:

# stop the accidental root gateway
sudo openclaw gateway stop || true
sudo kill -TERM 145364 || true
sleep 5
ps -fp 145364 || echo "root gateway stopped"

#

Then switch back to the real openclaw user and don’t use sudo for OpenClaw commands:

sudo -iu openclaw bash -lc '
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1

mkdir -p /var/tmp/openclaw-compile-cache

which openclaw
openclaw --version
openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart

#

openclaw gateway status --deep
openclaw channels status --probe
'

The correct output should say:

Config: /home/openclaw/.openclaw/openclaw.json

not /root/.openclaw/.... If it still shows /root, stop and paste that output.

#

Yep — that installed the gateway service under root:

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

We need undo that and reinstall under /home/openclaw.

From your normal shell, run this exact block:

# stop any accidental/root or wedged gateway
sudo pkill -f 'openclaw-gateway|openclaw gateway' || true

# disable the accidental root user unit by moving it aside
sudo mkdir -p /root/.config/systemd/user/disabled

#

sudo mv /root/.config/systemd/user/openclaw-gateway.service \
  /root/.config/systemd/user/disabled/openclaw-gateway.service.disabled 2>/dev/null || true

# start the openclaw user's systemd manager
OC_UID=$(id -u openclaw)
sudo loginctl enable-linger openclaw
sudo systemctl start user@${OC_UID}.service

# now run OpenClaw as the openclaw user, with the right HOME and user bus
sudo -u openclaw HOME=/home/openclaw \
  XDG_RUNTIME_DIR=/run/user/${OC_UID} \
  DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus \
  bash -lc '
    echo "HOME=$HOME"
    which openclaw

#

    openclaw --version
    openclaw doctor --repair
    openclaw gateway install --force
    openclaw gateway restart
    openclaw gateway status --deep
    openclaw channels status --probe
  '

The important check: it must print:

HOME=/home/openclaw

and not install anything under /root. If it still mentions /root/.openclaw or /root/.config, stop there and paste that output.

#

Good — we’re past the root-config mess now. This is the right config again:

Config: /home/openclaw/.openclaw/openclaw.json

Now 1006 abnormal closure means the gateway is accepting the socket and then closing/crashing. We need the fresh stack/log line.

Run this and paste/attach the output:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw \
  XDG_RUNTIME_DIR=/run/user/${OC_UID} \
  DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus \

#

  bash -lc '
    echo "== processes =="
    ps -ef | grep -E "openclaw-gateway|openclaw gateway" | grep -v grep || true

    echo "== stale openrouter plugin entry? =="
    openclaw config get plugins.entries.openrouter || true

    echo "== discord config =="
    openclaw config get channels.discord || true

    echo "== latest log =="
    tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
  '

If it still mentions:

#

plugins.entries.openrouter: plugin not found: openrouter

that’s likely the next blocker: stale plugin config causing startup/runtime breakage. If not, the latest log tail should show the actual crash reason. Redact tokens if any appear.

serene cypress Apr 29, 2026, 2:29 AM

#

openclaw@pi:~$ sudo mv /root/.config/systemd/user/openclaw-gateway.service
/root/.config/systemd/user/disabled/openclaw-gateway.service.disabled 2>/dev/null || true
OC_UID=$(id -u openclaw)
sudo loginctl enable-linger openclaw
sudo systemctl start user@${OC_UID}.service

fallen trailBOT Apr 29, 2026, 2:29 AM

#

Good. Now run the non-sudo OpenClaw part with the explicit env:

sudo -u openclaw HOME=/home/openclaw \
  XDG_RUNTIME_DIR=/run/user/${OC_UID} \
  DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus \
  bash -lc '
    echo "HOME=$HOME"
    which openclaw
    openclaw --version

    openclaw doctor --repair
    openclaw gateway install --force
    openclaw gateway restart
    sleep 10

#

    openclaw gateway status --deep
    openclaw channels status --probe
  '

If that still gives 1006, run the log pull:

sudo -u openclaw HOME=/home/openclaw \
  XDG_RUNTIME_DIR=/run/user/${OC_UID} \
  DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus \
  bash -lc '
    openclaw config get plugins.entries.openrouter || true
    openclaw config get channels.discord || true
    tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

#

Paste the first error/stack from that tail.

serene cypress Apr 29, 2026, 2:30 AM

#

sudo -u openclaw HOME=/home/openclaw
XDG_RUNTIME_DIR=/run/user/${OC_UID}
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus
bash -lc '
echo "HOME=$HOME"
which openclaw

It's just hanging there

fallen trailBOT Apr 29, 2026, 2:30 AM

#

You’re at the shell’s continuation prompt (>), not a hang — the single quote wasn’t closed.

Press Ctrl-C, then paste this shorter one-line version:

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'echo "HOME=$HOME"; which openclaw; openclaw --version; openclaw doctor --repair; openclaw gateway install --force; openclaw gateway restart; sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

If ${OC_UID} is empty, set it first:

OC_UID=$(id -u openclaw)

serene cypress Apr 29, 2026, 2:31 AM

#

openclaw@pi:~$ sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'echo "HOME=$HOME"; which openclaw; openclaw --version; openclaw doctor --repair; openclaw gateway install --force; openclaw gateway restart; sleep 10; openclaw gateway status --deep; openclaw channels status --probe'
HOME=/home/openclaw
/usr/local/bin/openclaw
OpenClaw 2026.4.26 (be8c246)

🦞 OpenClaw 2026.4.26 (be8c246) — The lobster in your shell. 🦞

Doctor is running now

fallen trailBOT Apr 29, 2026, 2:31 AM

#

Perfect — that’s the right user, right HOME, right binary now. Let doctor finish.

If it takes more than a few minutes on the Pi, that may just be slow plugin/state checks, but the next thing I’d want is its final output plus the gateway status --deep / channels status --probe results from the same command.

If it stalls for ~5+ minutes, Ctrl-C and rerun with the low-power env:

mkdir -p /var/tmp/openclaw-compile-cache
sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw doctor --repair; openclaw gateway install --force; openclaw gateway restart; sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

serene cypress Apr 29, 2026, 2:32 AM

#

OpenClaw doctor
│
◇ Gateway auth ─────────────────────────────────────────────────────────╮
│ │
│ Gateway token is managed via SecretRef and is currently unavailable. │
│ Doctor will not overwrite gateway.auth.token with a plaintext value. │
│ Resolve/rotate the external secret source, then rerun doctor. │
│ │
├────────────────────────────────────────────────────────────────────────╯
│
◇ Plugin registry ────────────────────────────────────────────╮
│ │
│ Plugin registry refreshed: 14/115 enabled plugins indexed. │
│ │
├──────────────────────────────────────────────────────────────╯
│
◇ State integrity ─────────────────────────────────────────────────────────────────────────╮
│ │
│ - Found 2 orphan transcript files in ~/.openclaw/agents/main/sessions. │
│ These .jsonl files are no longer referenced by sessions.json, so they are not part of │
│ any active session history. │
│ Doctor can archive them safely by renaming each file to *.deleted.<timestamp>. │
│ Examples: 4cfd93f3-fb8d-450c-98b9-bbce020e59a7.trajectory.jsonl, │
│ 6e9e0e8b-0db5-42ee-a3cf-a3c4d5c0d795.trajectory.jsonl

fallen trailBOT Apr 29, 2026, 2:32 AM

#

Aha — important new blocker:

Gateway token is managed via SecretRef and is currently unavailable.

That means the gateway service can’t resolve its auth token source. Fix/rotate that, then restart.

Simplest recovery is to set a fresh token directly in OpenClaw config as the openclaw user:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw \
  XDG_RUNTIME_DIR=/run/user/${OC_UID} \
  DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus \

#

  bash -lc '
    openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
    openclaw doctor --repair
    openclaw gateway install --force
    openclaw gateway restart
    sleep 10
    openclaw gateway status --deep
    openclaw channels status --probe
  '

This won’t touch your Discord token; it only fixes the local gateway auth token that CLI/control clients use.

If you intentionally use an external secret provider for gateway.auth.token, fix that provider instead — but for getting unstuck on the Pi, rotating to a direct token is the fastest path.

serene cypress Apr 29, 2026, 2:33 AM

#

Skills status ───────────╮
│ │
│ Eligible: 42 │
│ Missing requirements: 7 │
│ Blocked by allowlist: 0 │
│ │
├───────────────────────────╯
│
◇ Plugins ───────╮
│ │
│ Loaded: 14 │
│ Imported: 0 │
│ Disabled: 101 │
│ Errors: 0 │
│ │
├─────────────────╯
│
◇ Bootstrap file size ──────────────────────────────────────────────────╮
│ │
│ Workspace bootstrap files are near configured limits: │
│ - MEMORY.md: 11,343 chars (95% of max/file 12,000) │
│ Total bootstrap injected chars: 27,660 (46% of max/total 60,000). │
│ Total bootstrap raw chars (before truncation): 27,660. │
│ │
│ - Tip: tune agents.defaults.bootstrapMaxChars for per-file limits. │
│ │
├────────────────────────────────────────────────────────────────────────╯
│
◇
│
◇ Gateway ──────────────╮
│ │
│ Gateway not running. │
│ │
├────────────────────────╯
│
◇ Gateway connection ─────────────────────────────╮
│ │
│ Gateway target: ws://127.0.0.1:18789 │
│ Source: local loopback │
│ Config: /home/openclaw/.openclaw/openclaw.json │
│ Bind: loopback │
│ │

#

├──────────────────────────────────────────────────╯
│
◇ Memory search ──────────────────────────────────────────╮
│ │
│ Memory search is explicitly disabled (enabled: false). │
│ │
├──────────────────────────────────────────────────────────╯
│
◇ Gateway ──────────────────────────────────────────────────────────────────────────────────╮
│ │
│ Last gateway error: Gateway service check failed: Error: systemctl --user unavailable: │
│ Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and │
│ $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to │
│ bus of other user) │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Gateway ─────────────────────────────────────────────────────────────────────────╮
│ │
│ Runtime: running (pid 146909, state active, sub running, last exit 0, reason 0) │
│ │
├───────────────────────────────────────────────────────────────────────────────────╯
Restarted systemd service: openclaw-gateway.service

#

Gateway ──────────────╮
│ │
│ Gateway not running. │
│ │
├────────────────────────╯
│
◇ Gateway connection ─────────────────────────────╮
│ │
│ Gateway target: ws://127.0.0.1:18789 │
│ Source: local loopback │
│ Config: /home/openclaw/.openclaw/openclaw.json │
│ Bind: loopback │
│ │
├──────────────────────────────────────────────────╯
│
└ Doctor complete.

fallen trailBOT Apr 29, 2026, 2:33 AM

#

This is actually progress:

Config is now correct: /home/openclaw/.openclaw/openclaw.json
Root config mess is gone
Plugin errors are gone
No gateway auth warning in this paste
Current issue is simply: gateway not running

If the big command is still running, let it continue — it should install/restart after doctor.

If you’re back at the shell prompt, run:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw gateway install --force; openclaw gateway start; sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

#

If that still says gateway not running, paste the first error after gateway start and the latest log tail:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

#

Nice — service restarted and now has a new PID:

pid 146909

The “last gateway error” may just be stale from before. Check the live probe now:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

If it times out/1006 again, pull the fresh logs for this new PID:

#

tail -n 250 /tmp/openclaw/openclaw-2026-04-28.log

We’re looking for the first actual error after pid 146909 starts. If the live probe works, Discord should show up in channels status --probe; then we can fix any remaining Discord-specific config.

#

That Gateway not running is from inside doctor before the later restart. Since the command then printed Restarted systemd service with PID 146909, the live check is what matters now.

Run:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

If it says not running/timeout, paste:

ps -fp 146909 || true
tail -n 250 /tmp/openclaw/openclaw-2026-04-28.log

serene cypress Apr 29, 2026, 2:35 AM

#

Doctor complete.

🦞 OpenClaw 2026.4.26 (be8c246) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.26 (be8c246) — I'm like tmux: confusing at first, then suddenly you can't live without me.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 147139, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 147139 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789

fallen trailBOT Apr 29, 2026, 2:35 AM

#

This is the same core failure, just cleaner now:

service starts ✅
PID owns 127.0.0.1:18789 ✅
gateway RPC never answers ❌

The “Port already in use” line is expected because the gateway owns it. The real problem is the timeout.

Wait once, then probe again:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'sleep 60; openclaw gateway status --deep'

If it still times out, don’t restart again yet — pull the fresh log + process stats:

#

ps -fp 147139 -o pid,ppid,etime,%cpu,%mem,rss,cmd

tail -n 300 /tmp/openclaw/openclaw-2026-04-28.log

grep -Eina 'fatal|error|uncaught|timeout|auth|plugin|discord|gateway|1006|EADDRINUSE|listening|started' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 200

If the log doesn’t show the cause, run it in foreground once:

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'systemctl --user stop openclaw-gateway.service || true'

sudo kill -TERM 147139 || true
sleep 5

#

sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'mkdir -p /var/tmp/openclaw-compile-cache; openclaw gateway --port 18789'

Paste the first real error/stack from that foreground run. And yep: still avoid sudo openclaw ... — only use sudo for kill/system service bits.

serene cypress Apr 29, 2026, 2:37 AM

#

openclaw@pi:~$ OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw gateway install --force; openclaw gateway start; sleep 10; openclaw gateway status --deep; openclaw channels status --probe'

🦞 OpenClaw 2026.4.26 (be8c246) — Greetings, Professor Falken

gateway.auth.token is SecretRef-managed; install will not persist a resolved token in service environment. Ensure the SecretRef is resolvable in the daemon runtime context.

Installed systemd service: /home/openclaw/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/openclaw/.config/systemd/user/openclaw-gateway.service.bak

fallen trailBOT Apr 29, 2026, 2:38 AM

#

That warning means the gateway token is still SecretRef-managed and not available to the daemon. Fix that before chasing Discord.

If the current command is stuck, Ctrl-C. Then run this as-is:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc '
  openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
  openclaw doctor --repair
  openclaw gateway install --force
  openclaw gateway restart
  sleep 10
  openclaw gateway status --deep
  openclaw channels status --probe
'

#

Important: this only rotates the local gateway auth token, not your Discord bot token.

After this, the install warning about gateway.auth.token is SecretRef-managed should disappear. If it doesn’t, paste:

openclaw config get gateway.auth.token

Redact any actual token value if shown.

serene cypress Apr 29, 2026, 2:39 AM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 147968, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Gateway port 18789 is not listening (service appears running).
Last gateway error: Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart log: ~/.openclaw/logs/gateway-restart.log

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

🦞 OpenClaw 2026.4.26 (be8c246) — I'll refactor your busywork like it owes me money.

│
◇
Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback

#

Possible causes:

Gateway not yet ready to accept connections (retry after a moment)
TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
Gateway crashed or was terminated unexpectedly
Run openclaw doctor for diagnostics.
Gateway not reachable; showing config-only status.
Config: /home/openclaw/.openclaw/openclaw.json
Mode: local

fallen trailBOT Apr 29, 2026, 2:39 AM

#

Now we need the actual crash/startup error. This output means the service process exists, but the gateway either never binds or binds then immediately closes:

Gateway port 18789 is not listening
connect ECONNREFUSED
1006 abnormal closure

Run these and paste the error lines:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc '
  echo "== restart log =="
  tail -n 200 ~/.openclaw/logs/gateway-restart.log 2>/dev/null || true

#


  echo "== file log =="
  tail -n 300 /tmp/openclaw/openclaw-2026-04-28.log 2>/dev/null || true

  echo "== token config shape =="
  openclaw config get gateway.auth.token || true
'

If that still doesn’t show the failure, run foreground mode once:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'systemctl --user stop openclaw-gateway.service || true'

#


sudo pkill -f 'openclaw-gateway|openclaw gateway' || true

sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'mkdir -p /var/tmp/openclaw-compile-cache; openclaw gateway --port 18789'

Paste the first stack/error it prints. We’re finally past config/root/service confusion; this is now a gateway startup crash/hang.

#

Yep, that’s just the generic probe text. The next thing has to be the logs/foreground error — otherwise we’re blind.

Please run this exact log command:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc '
  echo "== restart log =="
  tail -n 200 ~/.openclaw/logs/gateway-restart.log 2>/dev/null || true

  echo "== file log =="
  tail -n 300 /tmp/openclaw/openclaw-2026-04-28.log 2>/dev/null || true

  echo "== errors only =="
  grep -Eina "fatal|error|uncaught|exception|denied|auth|token|plugin|discord|EADDRINUSE|listening|started|gateway" /tmp/openclaw/openclaw-2026-04-28.log 2>/dev/null | tail -n 200 || true

#

If it’s too long for Discord, attach it as a .txt file or just paste the == errors only == section.

serene cypress Apr 29, 2026, 2:47 AM

#

4422:{"0":"{"subsystem":"gateway"}","1":"log file: /tmp/openclaw/openclaw-2026-04-28.log","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-29T02:38:59.371Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-28T22:38:59.372-04:00","hostname":"pi","message":"log file: /tmp/openclaw/openclaw-2026-04-28.log"}
4423:{"0":"{"subsystem":"gateway"}","1":"security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-29T02:38:59.417Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/usr/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-28T22:38:59.418-04:00","hostname":"pi","message":"security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit."}

fallen trailBOT Apr 29, 2026, 2:47 AM

#

That log only reaches startup + the security warning — it never gets to “gateway listening”. So it’s hanging/crashing very early.

First, confirm the gateway token is no longer SecretRef-managed:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw config get gateway.auth.token'

If that prints an object like { source: ..., provider: ... }, replace it:

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw config set gateway.auth.token "$(openssl rand -hex 32)"'

Then run foreground so we can see exactly where it stops:

#

sudo pkill -f "openclaw-gateway|openclaw gateway" || true

sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'mkdir -p /var/tmp/openclaw-compile-cache; openclaw gateway --port 18789'

Paste whatever appears after the security warning. If it just sits there silently for 60s, say that — that’s useful too.

serene cypress Apr 29, 2026, 2:49 AM

#

22:48:15 [gateway] loading configuration…
22:48:15 [gateway] resolving authentication…
22:48:15 [gateway] starting...
22:48:30 [secrets] [SECRETS_GATEWAY_AUTH_SURFACE] gateway.auth.token is active. gateway.auth.mode is "token".
22:48:45 [gateway] starting HTTP server...
22:48:45 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/openclaw/.openclaw/canvas)
22:48:45 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
22:48:46 [gateway] agent model: openrouter/minimax/minimax-m2.7
22:48:46 [gateway] http server listening (9 plugins: browser, diffs, discord, llm-task, lobster, memory-core, skill-workshop, tokenjuice, webhooks; 30.6s)
22:48:46 [gateway] log file: /tmp/openclaw/openclaw-2026-04-28.log
22:48:46 [gateway] security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.
22:48:46 [gateway] starting channels and sidecars...
22:48:48 [hooks:loader] Loading managed hook code into the gateway process. Managed hooks are trusted local code.
22:48:49 [hooks] loaded 5 internal hook handlers

fallen trailBOT Apr 29, 2026, 2:49 AM

#

That looks much better — foreground gateway is supposed to keep running there. The key line is:

http server listening (...; 30.6s)

So don’t Ctrl-C yet. In a second terminal, run:

OC_UID=$(id -u openclaw)

sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'openclaw gateway status --deep; openclaw channels status --probe'

If that works, the gateway itself is alive and we’re back to Discord-specific status.

If Discord still isn’t connecting, paste the Discord lines:

#

grep -Eina 'discord|channel|ready|connected|disconnect|closed|1006|401|403|forbidden|intent|token|error|fatal|uncaught' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 200

Also: startup took ~30s on the Pi, so the earlier quick probes may have been racing startup a bit — but after “http server listening,” it should answer.

serene cypress Apr 29, 2026, 2:49 AM

#

22:49:24 [ws] handshake timeout conn=cdfc973f-cde9-4040-a1c6-2b32a47546e3 peer=127.0.0.1:33776->127.0.0.1:18789 remote=127.0.0.1
22:49:24 [ws] closed before connect conn=cdfc973f-cde9-4040-a1c6-2b32a47546e3 peer=127.0.0.1:33776->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 code=1000 reason=n/a

fallen trailBOT Apr 29, 2026, 2:49 AM

#

That line is from a browser/control UI connection timing out its WebSocket handshake, not Discord:

origin=http://127.0.0.1:18789
ua=Chrome ...

So two tracks now:

Gateway is running in foreground ✅
Control UI/CLI handshake is slow/timing out, likely because the Pi is overloaded during channel startup.

Let’s check Discord/channel status after giving it more time. In a second terminal:

OC_UID=$(id -u openclaw)

#


sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'sleep 90; openclaw channels status --probe'

And filter Discord logs:

grep -Eina 'discord|gateway.*ready|channel.*ready|connected|disconnect|closed|1006|401|403|forbidden|intent|invalid token|error|fatal|uncaught' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 200

If the foreground gateway stays up and Discord works, the remaining fix is to restart it as the systemd service with the low-power env persisted. But first let’s verify Discord actually reaches connected/ready.

serene cypress Apr 29, 2026, 2:53 AM

#

22:49:24 [ws] handshake timeout conn=cdfc973f-cde9-4040-a1c6-2b32a47546e3 peer=127.0.0.1:33776->127.0.0.1:18789 remote=127.0.0.1
22:49:24 [ws] closed before connect conn=cdfc973f-cde9-4040-a1c6-2b32a47546e3 peer=127.0.0.1:33776->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 code=1000 reason=n/a
22:52:47 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
22:52:48 [gateway] ready
22:52:48 [heartbeat] started
22:52:50 [ws] webchat connected conn=a7160840-14d8-4574-ba07-d74f34432e32 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.26
22:52:50 [ws] ⇄ res ✓ sessions.list 324ms conn=a7160840…2e32 id=8df9c01d…1f03
22:52:51 [ws] ⇄ res ✓ commands.list 1130ms conn=a7160840…2e32 id=f5ae2ed3…8124
22:52:51 [ws] ⇄ res ✓ health 1216ms conn=a7160840…2e32 id=adc73019…d997
22:52:52 [discord] [default] starting provider (@Pi-OC Home AI Bot)
22:52:53 [ws] ⇄ res ✓ node.list 3184ms conn=a7160840…2e32 id=01dbae45…722b
22:52:53 [ws] ⇄ res ✓ device.pair.list 3188ms conn=a7160840…2e32 id=3823fd2a…cf52

fallen trailBOT Apr 29, 2026, 2:53 AM

#

Excellent — gateway is healthy now:

[gateway] ready
[ws] webchat connected
[discord] starting provider

Startup is just very slow on the Pi: ~4.5 minutes from gateway start to ready. Earlier probes/restarts were probably interrupting it before it finished.

Now wait another minute or two and check Discord:

grep -Eina 'discord|ready|connected|disconnect|closed|401|403|forbidden|intent|invalid token|error|fatal|uncaught' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 100

If Discord reaches ready/connected, the fix is basically:

#

keep the corrected /home/openclaw systemd service
keep gateway.auth.token resolvable
stop using sudo openclaw ...
give the Pi several minutes after restart before probing

For Pi performance, I’d persist the low-power env too:

mkdir -p /var/tmp/openclaw-compile-cache

Then add to the user service environment if OpenClaw doesn’t already:

NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1

#

But first confirm the Discord provider reaches ready.

serene cypress Apr 29, 2026, 2:53 AM

#

openclaw@pi:~ $ sudo -u openclaw HOME=/home/openclaw XDG_RUNTIME_DIR=/run/user/${OC_UID} DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${OC_UID}/bus bash -lc 'sleep 90; openclaw channels status --probe'

🦞 OpenClaw 2026.4.26 (be8c246) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

│
◇
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /home/openclaw/.openclaw/openclaw.json
Mode: local

fallen trailBOT Apr 29, 2026, 2:53 AM

#

Okay, that changes the diagnosis: the gateway does become ready, then later becomes unresponsive again. Since the last meaningful line before that was:

[discord] [default] starting provider

Discord startup is likely wedging the gateway/event loop.

Don’t restart yet. Grab the lines after that point:

tail -n 300 /tmp/openclaw/openclaw-2026-04-28.log

And process stats:

#

ps -ef | grep -E 'openclaw-gateway|openclaw gateway' | grep -v grep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"

Quick isolation test after that: temporarily disable Discord and see if gateway stays healthy:

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep

If that stays healthy, re-enable Discord and we’ve confirmed the Discord provider is the trigger:

#

openclaw config set channels.discord.enabled true --strict-json

Then this is probably worth a GitHub issue with: Pi arm64, 2026.4.26, gateway ready → [discord] starting provider → RPC timeout. Redact tokens.

serene cypress Apr 29, 2026, 2:56 AM

#

openclaw@pi:~ $ ps -ef | grep -E 'openclaw-gateway|openclaw gateway' | grep -v grep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"
root 149191 145242 0 22:48 pts/3 00:00:00 sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/109 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/109/bus bash -lc mkdir -p /var/tmp/openclaw-compile-cache; openclaw gateway --port 18789
root 149193 149191 0 22:48 pts/4 00:00:00 sudo -u openclaw HOME=/home/openclaw NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache OPENCLAW_NO_RESPAWN=1 XDG_RUNTIME_DIR=/run/user/109 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/109/bus bash -lc mkdir -p /var/tmp/openclaw-compile-cache; openclaw gateway --port 18789
openclaw 149194 149193 99 22:48 pts/4 00:08:36 openclaw-gateway
PID ELAPSED %CPU %MEM RSS CMD
149194 08:23 102 7.8 631488 openclaw-gateway

fallen trailBOT Apr 29, 2026, 2:57 AM

#

That’s the smoking gun now:

openclaw-gateway 99–102% CPU

So the gateway isn’t “starting slowly” anymore — it’s CPU-spinning/wedged.

Please do this next:

Capture the end of the log first:

tail -n 400 /tmp/openclaw/openclaw-2026-04-28.log

Then isolate Discord as the trigger. Stop the foreground gateway with Ctrl-C, then:

#

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway --port 18789

In another terminal after ~2 minutes:

openclaw gateway status --deep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"

If CPU stays normal with Discord disabled, we’ve confirmed the Discord provider is wedging 2026.4.26 on your Pi. Re-enable after the test:

openclaw config set channels.discord.enabled true --strict-json

#

At that point this is GitHub-issue territory with the log tail + repro: Pi arm64, 2026.4.26, gateway ready → [discord] starting provider → 100% CPU/RPC timeout. Redact tokens.

serene cypress Apr 29, 2026, 2:59 AM

#

22:52:52 [discord] [default] starting provider (@Pi-OC Home AI Bot)
22:52:53 [ws] ⇄ res ✓ node.list 3184ms conn=a7160840…2e32 id=01dbae45…722b
22:52:53 [ws] ⇄ res ✓ device.pair.list 3188ms conn=a7160840…2e32 id=3823fd2a…cf52
22:54:11 [ws] ⇄ res ✓ chat.history 81002ms conn=a7160840…2e32 id=af855061…449b
22:54:11 [ws] ⇄ res ✓ models.list 81034ms conn=a7160840…2e32 id=53c1088a…e086
22:55:51 [ws] ⇄ res ✓ node.list 576ms conn=a7160840…2e32 id=e8dfbb66…5761
22:58:01 [discord] channel resolve failed; using config entries. fetch failed | write EPIPE
22:58:01 [discord] users resolved: 803303300048093194
22:58:01 [discord] channel users resolved: 803303300048093194
22:58:01 [ws] ⇄ res ✓ node.list 220ms conn=a7160840…2e32 id=8484d1a2…df98
22:58:04 [discord] logged in to discord as 1484046556813590578 (Pi-OC Home AI Bot)
22:58:07 [ws] ⇄ res ✓ channels.status 319182ms conn=7fb54ebd…c71c id=4e6bdc7d…5163
22:58:12 [agent/embedded] [tools] No callable tools remain after resolving explicit tool allowlist (tools.allow: *, read, write, web_search, web_fetch, llm-task, lobster); tools are disabled for this run. Fix the allowlist or enable the plugin that registers the requested tool.
22:58:12 [agent/embedded] embedded run failover decision: runId=skill-workshop-review-0bdfbb70-2c0f-4025-add0-0c93ff203d61 stage=prompt decision=surface_error reason=none from=openrouter/minimax/minimax-m2.7 profile=sha256:ac092b59b472 rawError=No callable tools remain after resolving explicit tool allowlist (tools.allow: *, read, write, web_search, web_fetch, llm-task, lobster); tools are disabled for this run. Fix the allowlist or enable t…

fallen trailBOT Apr 29, 2026, 3:00 AM

#

Aha, this is no longer “Discord can’t connect.”

Your log shows Discord did log in:

[discord] logged in to discord as ... (Pi-OC Home AI Bot)

The bigger issue is the gateway is getting badly blocked:

channels.status 319182ms
openclaw-gateway 102% CPU

And the next suspicious line is skill-workshop-review... No callable tools remain.... I’d temporarily disable skill-workshop and retest:

#

openclaw config set plugins.entries.skill-workshop.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep
openclaw channels status --probe

If gateway stays responsive after that, we found the trigger.

Also check/fix your tool allowlist later — this is probably misconfigured:

tools.allow: *, read, write, web_search, web_fetch, llm-task, lobster

Docs say valid groups include group:fs, group:web, group:runtime, etc. https://docs.openclaw.ai/gateway/config-tools

#

For now: disable skill-workshop, restart, wait several minutes on the Pi, then check if Discord remains connected.

serene cypress Apr 29, 2026, 3:08 AM

#

still waiting on the gateway and channels status, but isn't it supposed to be in the openclaw wrapper, not node?

openclaw@pi:~ $ journalctl --user -u openclaw-gateway -f
Apr 28 23:05:07 pi node[150851]: 2026-04-28T23:05:07.295-04:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
Apr 28 23:05:08 pi node[150851]: 2026-04-28T23:05:08.512-04:00 [gateway] agent model: openrouter/minimax/minimax-m2.7
Apr 28 23:05:08 pi node[150851]: 2026-04-28T23:05:08.521-04:00 [gateway] http server listening (8 plugins: browser, diffs, discord, llm-task, lobster, memory-core, tokenjuice, webhooks; 46.6s)
Apr 28 23:05:08 pi node[150851]: 2026-04-28T23:05:08.529-04:00 [gateway] log file: /tmp/openclaw/openclaw-2026-04-28.log
Apr 28 23:05:09 pi node[150851]: 2026-04-28T23:05:09.053-04:00 [gateway] security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.
Apr 28 23:05:09 pi node[150851]: 2026-04-28T23:05:09.070-04:00 [gateway] starting channels and sidecars...
Apr 28 23:05:14 pi node[150851]: 2026-04-28T23:05:14.608-04:00 [hooks:loader] Loading managed hook code into the gateway process. Managed hooks are trusted local code.
Apr 28 23:05:14 pi node[150851]: 2026-04-28T23:05:14.816-04:00 [hooks] loaded 5 internal hook handlers
Apr 28 23:06:32 pi node[150851]: 2026-04-28T23:06:32.956-04:00 [ws] handshake timeout conn=85c441fa-b7b7-44a6-a402-2ade7a32c49a peer=127.0.0.1:54742->127.0.0.1:18789 remote=127.0.0.1
Apr 28 23:06:35 pi node[150851]: 2026-04-28T23:06:35.939-04:00 [ws] closed before connect conn=85c441fa-b7b7-44a6-a402-2ade7a32c49a peer=127.0.0.1:54742->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 code=1000 reason=n/a

fallen trailBOT Apr 29, 2026, 3:09 AM

#

Yep, seeing node[...] in journalctl is normal. The OpenClaw CLI wrapper is just a launcher; the installed service can exec Node directly:

/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

That part is fine.

The weird part is still that the gateway reaches:

http server listening ... starting channels and sidecars...

then the event loop gets so busy that local WS handshakes time out. Since disabling skill-workshop dropped plugins from 9 → 8, that part worked, but the hang remains.

Next best isolation test is Discord off:

#

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep

If it stays responsive with Discord disabled, then Discord provider startup is the culprit. If it still wedges, the culprit is another startup sidecar/hook/plugin on this Pi.

Also grab CPU while it’s “waiting”:

ps -o pid,etime,%cpu,%mem,rss,cmd -p 150851

serene cypress Apr 29, 2026, 3:12 AM

#

so should the install be "local" to my openclaw@pi user?
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 150851, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 150851 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status

#

Apr 28 23:09:47 pi node[150851]: 2026-04-28T23:09:47.536-04:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
Apr 28 23:09:51 pi node[150851]: 2026-04-28T23:09:51.009-04:00 [gateway] ready
Apr 28 23:09:51 pi node[150851]: 2026-04-28T23:09:51.040-04:00 [heartbeat] started
Apr 28 23:09:51 pi node[150851]: 2026-04-28T23:09:51.121-04:00 [discord] [default] starting provider
Apr 28 23:09:52 pi node[150851]: 2026-04-28T23:09:52.664-04:00 [ws] webchat connected conn=d0329286-d868-4d31-bb25-9d98c4a35af8 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.26
Apr 28 23:09:53 pi node[150851]: 2026-04-28T23:09:53.695-04:00 [ws] ⇄ res ✓ sessions.subscribe 993ms conn=d0329286…5af8 id=38bd4707…e5e3
Apr 28 23:09:53 pi node[150851]: 2026-04-28T23:09:53.711-04:00 [ws] ⇄ res ✓ agent.identity.get 1009ms conn=d0329286…5af8 id=10697b11…11e0
Apr 28 23:09:53 pi node[150851]: 2026-04-28T23:09:53.722-04:00 [ws] ⇄ res ✓ agents.list 1018ms conn=d0329286…5af8 id=32968f3c…153b
Apr 28 23:09:53 pi node[150851]: 2026-04-28T23:09:53.731-04:00 [ws] ⇄ res ✓ health 1025ms cached=true conn=d0329286…5af8 id=457a0085…7bb4
Apr 28 23:09:55 pi node[150851]: 2026-04-28T23:09:55.481-04:00 [ws] ⇄ res ✓ sessions.list 2766ms conn=d0329286…5af8 id=138c9064…e585
Apr 28 23:09:58 pi node[150851]: 2026-04-28T23:09:58.496-04:00 [ws] ⇄ res ✓ commands.list 1996ms conn=d0329286…5af8 id=94f91fd9…f161
Apr 28 23:09:58 pi node[150851]: 2026-04-28T23:09:58.699-04:00 [ws] ⇄ res ✓ node.list 5992ms conn=d0329286…5af8 id=e381134f…c141
Apr 28 23:09:58 pi node[150851]: 2026-04-28T23:09:58.708-04:00 [ws] ⇄ res ✓ device.pair.list 6000ms conn=d0329286…5af8 id=7b06634f…45f2
Apr 28 23:11:17 pi node[150851]: 2026-04-28T23:11:17.129-04:00 [ws] closed before connect conn=a817040a-8331-4052-b8ae-57caee3e1f37 peer=127.0.0.1:51646->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a

fallen trailBOT Apr 29, 2026, 3:12 AM

#

Yes — the service should be installed as the openclaw user, and your output now looks like it is:

Service file: ~/.config/systemd/user/openclaw-gateway.service
Config: ~/.openclaw/openclaw.json
Runtime pid owned by openclaw

It’s okay that the command uses global Node:

/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway

That’s just the global OpenClaw install being launched by the user service. The bad case was when it installed under /root/...; that appears fixed.

Current problem is different: the openclaw user’s gateway is listening but the event loop is blocked, so probes timeout.

#

Please run:

ps -o pid,etime,%cpu,%mem,rss,cmd -p 150851

If it’s high CPU again, isolate with Discord disabled:

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep

If the gateway stays healthy with Discord off, the issue is Discord provider startup on 2026.4.26/Pi. If it still wedges with Discord off, it’s likely another plugin/hook/sidecar.

#

Yeah, this points really strongly at Discord provider startup wedging the event loop:

[gateway] ready
[discord] [default] starting provider
...
then later WS 1006 / probes timeout

Also notice there’s no later:

[discord] logged in ...

in this run.

#

Please do the Discord-off isolation. From the openclaw user:

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"

If that stays responsive / CPU normal, leave Discord disabled for now and file a GitHub issue with:

OpenClaw 2026.4.26
Raspberry Pi arm64
Node 22.22.2
log: gateway ready → Discord starting provider → no login → gateway RPC timeout / 100% CPU
note that disabling skill-workshop didn’t fix it

#

Issue link: https://github.com/openclaw/openclaw/issues

If it still wedges with Discord disabled, then we’ll look at hooks/browser/memory-core next.

serene cypress Apr 29, 2026, 3:14 AM

#

Ok, I had previously run: sed -i 's|ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js|ExecStart=/usr/local/bin/openclaw|' ~/.config/systemd/user/openclaw-gateway.service

fallen trailBOT Apr 29, 2026, 3:15 AM

#

Ah, yep — that explains some of the service weirdness. Don’t hand-edit the unit; let OpenClaw regenerate it. The Node ExecStart is expected for the installed service.

Run:

openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart
openclaw gateway status --deep

Then verify the unit:

systemctl --user cat openclaw-gateway.service

#

It should be fine if it shows something like:

ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

The wrapper is for interactive CLI use; systemd running Node directly is normal and avoids extra launcher/self-respawn overhead.

serene cypress Apr 29, 2026, 3:18 AM

#

openclaw@pi:~ $ openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart
openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

gateway.auth.token is SecretRef-managed; install will not persist a resolved token in service environment. Ensure the SecretRef is resolvable in the daemon runtime context.

Installed systemd service: /home/openclaw/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/openclaw/.config/systemd/user/openclaw-gateway.service.bak

🦞 OpenClaw 2026.4.26 (be8c246) — Hot reload for config, cold sweat for deploys.

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.26 (be8c246) — Deployed locally, trusted globally, debugged eternally.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 152480, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 152480 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789

fallen trailBOT Apr 29, 2026, 3:18 AM

#

The unit is fixed now, but this warning is still not fixed:

gateway.auth.token is SecretRef-managed

That means the service may still not be able to resolve its gateway auth token reliably. Let’s remove that variable from the equation.

Run:

openclaw config get gateway.auth.token

If it prints a SecretRef object (source, provider, id, etc.), replace it with a direct token:

#

openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
openclaw config get gateway.auth.token
openclaw gateway install --force
openclaw gateway restart

After that, the gateway.auth.token is SecretRef-managed warning should be gone.

Then wait longer than the Pi startup time we saw:

sleep 300
openclaw gateway status --deep
openclaw channels status --probe
ps -o pid,etime,%cpu,%mem,rss,cmd -p 152480

#

If it’s still timing out and CPU is high, do the Discord-off test next.

serene cypress Apr 29, 2026, 3:20 AM

#

the token is saved in .env
openclaw@pi:~ $ openclaw config get gateway.auth.token

🦞 OpenClaw 2026.4.26 (be8c246) — If it works, it's automation; if it breaks, it's a "learning opportunity."

{
"source": "env",
"provider": "default",
"id": "GATEWAY_AUTH_TOKEN"

fallen trailBOT Apr 29, 2026, 3:20 AM

#

Got it. Even if it’s in .env, the installer warning means OpenClaw is warning it won’t bake that resolved value into the service env. It may work if the daemon loads ~/.openclaw/.env, but given all the auth/handshake noise, I’d simplify this.

For now, rotate it to a direct config token:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-tokenref
openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
openclaw gateway install --force
openclaw gateway restart
sleep 300
openclaw gateway status --deep

If you really want to keep the env SecretRef, verify the daemon can read it:

#

grep '^GATEWAY_AUTH_TOKEN=' ~/.openclaw/.env
systemctl --user show openclaw-gateway.service -p Environment

But direct token is the fastest way to remove this as a variable while debugging.

serene cypress Apr 29, 2026, 3:22 AM

#

it worked
openclaw@pi:~$ grep '^GATEWAY_AUTH_TOKEN=' ~/.openclaw/.env
systemctl --user show openclaw-gateway.service -p Environment
GATEWAY_AUTH_TOKEN=********
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

fallen trailBOT Apr 29, 2026, 3:22 AM

#

Nice — that confirms the .env has the token.

The systemctl --user show failure is just your shell not having the user bus env. Use either:

export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
systemctl --user show openclaw-gateway.service -p Environment

or:

sudo systemctl --machine=openclaw@.host --user show openclaw-gateway.service -p Environment

If the gateway is now responding, great. If not, I’d still do the direct-token simplification or move on to the Discord-off isolation. The important part: the service is correctly installed under /home/openclaw now, and the Node ExecStart is normal.

serene cypress Apr 29, 2026, 3:23 AM

#

openclaw@pi:~ $ openclaw gateway status --deep
openclaw channels status --probe
ps -o pid,etime,%cpu,%mem,rss,cmd -p 152480

🦞 OpenClaw 2026.4.26 (be8c246) — Running on your hardware, reading your logs, judging nothing (mostly).

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 152480, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 152480 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.26 (be8c246) — Powered by open source, sustained by spite and good documentation.

│
◇
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /home/openclaw/.openclaw/openclaw.json
Mode: local

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
PID ELAPSED %CPU %MEM RSS CMD
152480 05:24 105 10.1 815472 openclaw-gateway

fallen trailBOT Apr 29, 2026, 3:23 AM

#

That’s confirmed: it’s wedged again at 105% CPU. This is no longer auth/service install.

Do the isolation now:

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"

If that stays responsive/low CPU, Discord provider is the trigger.

If it still wedges with Discord disabled, disable browser next:

#

openclaw config set plugins.entries.browser.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep

But start with Discord — your logs show the hang happens right after [discord] starting provider.

serene cypress Apr 29, 2026, 3:30 AM

#

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.26 (be8c246) — I autocomplete your thoughts—just slower and with more API calls.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 153599, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
PID ELAPSED %CPU %MEM RSS CMD
151440 23:28 0.0 0.3 26016 journalctl --user -u openclaw-gateway -f

fallen trailBOT Apr 29, 2026, 3:31 AM

#

Great — that confirms it. With Discord disabled, the gateway is healthy:

Connectivity probe: ok
Capability: admin-capable

Tiny note: your ps command matched journalctl, not the gateway. Use:

ps -o pid,etime,%cpu,%mem,rss,cmd -p 153599

But the main diagnosis is now solid: Discord provider is triggering the wedge on your Pi / 2026.4.26 setup.

For now, leave Discord disabled if you need the gateway stable. Then file a GitHub issue: https://github.com/openclaw/openclaw/issues

#

Include:

OpenClaw 2026.4.26 (be8c246)
Raspberry Pi arm64, Node 22.22.2
service is correctly under /home/openclaw, direct Node ExecStart is normal
gateway healthy with channels.discord.enabled=false
gateway wedges at ~100% CPU after [discord] [default] starting provider
previous log included write EPIPE during Discord channel resolve and sometimes eventually login
skill-workshop disabled did not resolve it

That’s enough for maintainers to chase the Discord startup loop.

serene cypress Apr 29, 2026, 3:37 AM

#

What should I say for these in the bug:

Summary
Steps to reproduce
Expected behavior
Actual behavior

fallen trailBOT Apr 29, 2026, 3:37 AM

#

Use this:

Summary
Discord provider on Raspberry Pi arm64 causes gateway to wedge at ~100% CPU after startup on OpenClaw 2026.4.26. Gateway is healthy when channels.discord.enabled=false.

Steps to reproduce

Run OpenClaw 2026.4.26 (be8c246) on Raspberry Pi arm64 with Node 22.22.2.
Enable Discord channel with a valid bot token.
Start/restart the gateway via systemd user service.
Wait for gateway startup.

Observe logs around:

[gateway] ready
[discord] [default] starting provider

Run:

#

   openclaw gateway status --deep
   ps -o pid,etime,%cpu,%mem,rss,cmd -p <gateway_pid>

Disable Discord:

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart

Observe gateway becomes responsive again.

Expected behavior
Discord provider should start, log in, keep gateway responsive, and allow openclaw gateway status --deep / openclaw channels status --probe to complete normally.

Actual behavior
Gateway starts and listens on 127.0.0.1:18789, but after Discord provider startup it becomes unresponsive. CLI probes time out, WebSocket connections close with 1006, and openclaw-gateway spins around 100% CPU. With Discord disabled, gateway reports Connectivity probe: ok and Capability: admin-capable.

#

Useful log snippets to include:

[gateway] ready
[discord] [default] starting provider
[ws] closed before connect ... code=1006

and if you have it:

[discord] channel resolve failed; using config entries. fetch failed | write EPIPE
[discord] logged in to discord as ...

serene cypress Apr 29, 2026, 3:41 AM

#

https://github.com/openclaw/openclaw/issues/74044

fallen trailBOT Apr 29, 2026, 3:42 AM

#

Perfect — that issue has the key repro details and evidence. I’d just add any fresh tail logs if you get more, especially the exact CPU line and the “Discord disabled = healthy” output. (github.com)

Thanks for filing it — this is much better than us guessing config at this point.

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

serene cypress Apr 29, 2026, 3:44 AM

#

so do I have two installs at /usr/bin/node and /usr/local/bin/openclaw?

fallen trailBOT Apr 29, 2026, 3:45 AM

#

Not necessarily. That’s usually one OpenClaw install plus the Node runtime:

/usr/bin/node = Node.js executable
/usr/local/bin/openclaw = CLI wrapper/shim
/usr/lib/node_modules/openclaw/dist/index.js = actual installed OpenClaw package code

The systemd service running this is normal:

/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

To check for duplicate OpenClaw installs:

which -a openclaw

#

readlink -f "$(which openclaw)"
npm root -g
npm ls -g openclaw --depth=0

If those all point to /usr/local/bin/openclaw → /usr/lib/node_modules/openclaw/..., you’re fine. The bad duplicate earlier was the root user service/config, not necessarily two package installs.

serene cypress Apr 29, 2026, 3:46 AM

#

openclaw@pi:~ $ which openclaw
/usr/local/bin/openclaw
openclaw@pi:~ $ which -a openclaw
/usr/local/bin/openclaw
/usr/bin/openclaw
/bin/openclaw
/usr/local/bin/openclaw
/usr/bin/openclaw
/bin/openclaw
openclaw@pi:~ $ readlink -f "$(which openclaw)"
npm root -g
npm ls -g openclaw --depth=0
/usr/lib/node_modules/openclaw/openclaw.mjs
/home/openclaw/.local/lib/node_modules
/home/openclaw/.local/lib
└── (empty)

fallen trailBOT Apr 29, 2026, 3:46 AM

#

You do have multiple shims, but they may all point to the same install. Check:

ls -l /usr/local/bin/openclaw /usr/bin/openclaw /bin/openclaw
readlink -f /usr/local/bin/openclaw /usr/bin/openclaw /bin/openclaw
/usr/local/bin/openclaw --version
/usr/bin/openclaw --version
/bin/openclaw --version

Your active one is:

/usr/local/bin/openclaw -> /usr/lib/node_modules/openclaw/openclaw.mjs

But npm root -g as the openclaw user points to:

#

/home/openclaw/.local/lib/node_modules

and that has no OpenClaw. That suggests OpenClaw was installed system-wide, probably with sudo/root, and the openclaw user is just using the system shim. That’s not automatically bad, but it’s worth checking all shims resolve to the same 2026.4.26.

If /usr/bin/openclaw or /bin/openclaw resolve differently or show a different version, remove the stale ones or ensure /usr/local/bin stays first in PATH.

serene cypress Apr 29, 2026, 3:47 AM

#

openclaw@pi:~ $ ls -l /usr/local/bin/openclaw /usr/bin/openclaw /bin/openclaw
readlink -f /usr/local/bin/openclaw /usr/bin/openclaw /bin/openclaw
/usr/local/bin/openclaw --version
/usr/bin/openclaw --version
/bin/openclaw --version
lrwxrwxrwx 1 root root 41 Apr 28 15:39 /bin/openclaw -> ../lib/node_modules/openclaw/openclaw.mjs
lrwxrwxrwx 1 root root 41 Apr 28 15:39 /usr/bin/openclaw -> ../lib/node_modules/openclaw/openclaw.mjs
lrwxrwxrwx 1 root root 43 Apr 12 15:20 /usr/local/bin/openclaw -> /usr/lib/node_modules/openclaw/openclaw.mjs
/usr/lib/node_modules/openclaw/openclaw.mjs
/usr/lib/node_modules/openclaw/openclaw.mjs
/usr/lib/node_modules/openclaw/openclaw.mjs
OpenClaw 2026.4.26 (be8c246)
OpenClaw 2026.4.26 (be8c246)
OpenClaw 2026.4.26 (be8c246)

fallen trailBOT Apr 29, 2026, 3:47 AM

#

That’s fine — all three shims resolve to the same install and same version:

/usr/lib/node_modules/openclaw/openclaw.mjs
OpenClaw 2026.4.26 (be8c246)

So you do not have a split binary install problem now. The earlier split was root/user service/config state, not multiple OpenClaw versions.

Current state:

install path: OK
systemd unit command: OK
service under openclaw user: OK
gateway healthy when Discord disabled: OK
gateway wedges when Discord enabled: likely bug from issue #74044

#

I’d leave Discord disabled for stability until maintainers reply, or try rolling back to the last version that worked for you if you need Discord immediately.

serene cypress Apr 29, 2026, 3:48 AM

#

anything I need to do about these shims? I had tried a docker install originally that didn't have enough head room on the Pi before changing installs, then later found a competing gateway instance I'd like to prevent

fallen trailBOT Apr 29, 2026, 3:48 AM

#

No action needed on the shims — they all resolve to the same 2026.4.26 install, so they’re harmless.

To prevent competing gateways, I’d clean/check these instead:

# check OpenClaw processes
ps -ef | grep -E 'openclaw-gateway|openclaw gateway' | grep -v grep

# check anything listening on gateway ports
ss -ltnp | grep -E '18789|18791'

# check user + root systemd units
systemctl --user status openclaw-gateway.service
sudo systemctl status openclaw-gateway.service 2>/dev/null || true
sudo ls -l /root/.config/systemd/user/openclaw-gateway.service 2>/dev/null || true

#

# check Docker leftovers
docker ps -a 2>/dev/null | grep -i openclaw || true

If Docker shows old OpenClaw containers, stop/remove those. If root has an OpenClaw user unit left, keep it disabled/moved aside. The goal is exactly one process: openclaw user owning openclaw-gateway on port 18789.

serene cypress Apr 29, 2026, 3:50 AM

#

openclaw 151440 115512 0 23:07 pts/0 00:00:00 journalctl --user -u openclaw-gateway -f
openclaw 153599 1292 29 23:24 ? 00:07:05 openclaw-gateway
LISTEN 0 511 127.0.0.1:18791 0.0.0.0:* users:(("openclaw-gatewa",pid=153599,fd=30))
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=153599,fd=25))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=153599,fd=26))
● openclaw-gateway.service - OpenClaw Gateway (v2026.4.26)
Loaded: loaded (/home/openclaw/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Tue 2026-04-28 23:24:36 EDT; 24min ago
Invocation: 3d5197bad00d4e52a7b0977fbd66a345
Main PID: 153599 (openclaw-gatewa)
Tasks: 11 (limit: 8746)
CPU: 7min 5.683s
CGroup: /user.slice/user-109.slice/user@109.service/app.slice/openclaw-gateway.service
└─153599 openclaw-gateway

Apr 28 23:25:41 pi node[153599]: 2026-04-28T23:25:41.543-04:00 [ws] ⇄ res ✗ chat.history 2419ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=84e01a55…5173 id=e97c79bb…8ac3
Apr 28 23:25:41 pi node[153599]: 2026-04-28T23:25:41.601-04:00 [ws] ⇄ res ✓ sessions.list 2475ms conn=84e01a55…5173 id=92d46d1a…dd26
Apr 28 23:25:41 pi node[153599]: 2026-04-28T23:25:41.609-04:00 [ws] ⇄ res ✗ models.list 2480ms errorCode=UNAVAILABLE errorMessage=models.list unavailable during gateway startup conn=84e01a55…5173 id=c1ffba5b…fb62
Apr 28 23:25:44 pi node[153599]: 2026-04-28T23:25:44.241-04:00 [ws] ⇄ res ✓ commands.list 5112ms conn=84e01a55…5173 id=a15c5743…bf28
Apr 28 23:27:04 pi node[153599]: 2026-04-28T23:27:04.017-04:00 [ws] ⇄ res ✗ chat.history 2ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=84e01a55…5173 id=24b3ff31…f0fb

#

Apr 28 23:27:10 pi node[153599]: 2026-04-28T23:27:10.110-04:00 [ws] ⇄ res ✓ node.list 90987ms conn=84e01a55…5173 id=aa38ccde…300e
Apr 28 23:27:10 pi node[153599]: 2026-04-28T23:27:10.120-04:00 [ws] ⇄ res ✓ device.pair.list 90996ms conn=84e01a55…5173 id=17c77882…f53f
Apr 28 23:29:54 pi node[153599]: 2026-04-28T23:29:54.932-04:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
Apr 28 23:29:58 pi node[153599]: 2026-04-28T23:29:58.074-04:00 [gateway] ready
Apr 28 23:29:58 pi node[153599]: 2026-04-28T23:29:58.092-04:00 [heartbeat] started

fallen trailBOT Apr 29, 2026, 3:50 AM

#

This looks clean from a “competing gateway” perspective:

Only one real gateway: PID 153599
It owns both expected ports:
- 18789 gateway/control UI
- 18791 browser control
Service is under /home/openclaw/.config/systemd/user/...
The journalctl -f process is harmless; it’s just your log tail

So no shim/process cleanup needed there.

But the gateway still looks stuck in “startup” after 24 minutes:

chat.history unavailable during gateway startup
models.list unavailable during gateway startup

#

If Discord is currently disabled, that means the hang isn’t only Discord. Check the current config:

openclaw config get channels.discord.enabled
openclaw gateway status --deep
ps -o pid,etime,%cpu,%mem,rss,cmd -p 153599

If Discord is disabled and CPU is still high, next suspects are startup hooks/sidecars/plugins. Since browser is active (18791), try disabling browser temporarily:

openclaw config set plugins.entries.browser.enabled false --strict-json
openclaw gateway restart
sleep 300
openclaw gateway status --deep
ps -o pid,etime,%cpu,%mem,rss,cmd -p "$(pgrep -f 'openclaw-gateway' | head -1)"

#

If that fixes startup, add that to issue #74044 too: Discord-off wasn’t sufficient / browser sidecar may also be involved.

#

Ah — then it eventually did finish startup:

23:29:58 [gateway] ready

So the “startup unavailable” lines were just because startup took ~5 minutes on the Pi. That’s slow, but not necessarily wedged.

Now run a fresh live check:

openclaw gateway status --deep
openclaw channels status --probe
ps -o pid,etime,%cpu,%mem,rss,cmd -p 153599
openclaw config get channels.discord.enabled

#

If Discord is disabled and the gateway is responsive, you’re stable.

If you re-enable Discord later, expect the bug to come back based on earlier isolation. For now the only thing I’d do is leave Discord off and maybe keep browser enabled unless it proves problematic.

serene cypress Apr 29, 2026, 3:52 AM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.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 153599, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

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

🦞 OpenClaw 2026.4.26 (be8c246) — The only crab in your contacts you actually want to hear from. 🦞

│
◇
Gateway reachable.

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
PID ELAPSED %CPU %MEM RSS CMD
153599 27:36 27.4 6.4 517056 openclaw-gateway

🦞 OpenClaw 2026.4.26 (be8c246) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

false

fallen trailBOT Apr 29, 2026, 3:52 AM

#

Great — that’s a stable baseline now:

Gateway reachable ✅
Admin-capable ✅
Single openclaw user service ✅
Discord disabled ✅

CPU at ~27% is still a little spicy but much better than 100% and responsive.

I’d leave it like this until maintainers look at #74044. If you need to test Discord again later:

openclaw config set channels.discord.enabled true --strict-json
openclaw gateway restart

…but expect the wedge to come back. To return to stable:

#

openclaw config set channels.discord.enabled false --strict-json
openclaw gateway restart

For the issue, this final evidence is useful: with channels.discord.enabled=false, gateway status --deep is Connectivity probe: ok / admin-capable.

serene cypress Apr 29, 2026, 4:01 AM

#

Apr 28 23:52:13 pi node[153599]: 2026-04-28T23:52:13.096-04:00 [ws] ⇄ res ✓ channels.status 3168ms conn=4abb7bab…2ce6 id=70b63ad5…3927
Apr 28 23:52:52 pi node[153599]: 2026-04-28T23:52:52.927-04:00 [ws] ⇄ res ✓ sessions.list 100ms conn=84e01a55…5173 id=4a21ff0e…500f
Apr 28 23:52:56 pi node[153599]: 2026-04-28T23:52:56.718-04:00 [ws] ⇄ res ✓ commands.list 3889ms conn=84e01a55…5173 id=56e03c10…b8cd
Apr 28 23:52:56 pi node[153599]: 2026-04-28T23:52:56.801-04:00 [ws] ⇄ res ✓ node.list 53ms conn=84e01a55…5173 id=f7998aeb…48d7
Apr 28 23:55:32 pi node[153599]: 2026-04-28T23:55:32.209-04:00 [ws] ⇄ res ✓ chat.history 159603ms conn=84e01a55…5173 id=9db3991a…6376
Apr 28 23:55:32 pi node[153599]: 2026-04-28T23:55:32.244-04:00 [ws] ⇄ res ✓ models.list 159416ms conn=84e01a55…5173 id=82f6720c…4b02
Apr 28 23:55:37 pi node[153599]: 2026-04-28T23:55:37.779-04:00 [ws] ⇄ res ✓ node.list 77233ms conn=84e01a55…5173 id=950e8c2e…0623
Apr 28 23:57:09 pi node[153599]: 2026-04-28T23:57:09.973-04:00 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:discord:direct:803303300048093194 state=processing age=155s queueDepth=1
Apr 28 23:57:14 pi node[153599]: 2026-04-28T23:57:14.255-04:00 [ws] ⇄ res ✓ node.list 92ms conn=84e01a55…5173 id=2fa3e8ea…c062
Apr 28 23:59:50 pi node[153599]: 2026-04-28T23:59:50.006-04:00 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:discord:direct:803303300048093194 state=processing age=315s queueDepth=1
Apr 29 00:00:04 pi node[153599]: 2026-04-29T00:00:04.112-04:00 [ws] ⇄ res ✓ node.list 185ms conn=84e01a55…5173 id=dfd96244…d481
Apr 29 00:00:04 pi node[153599]: 2026-04-29T00:00:04.939-04:00 [ws] ⇄ res ✓ sessions.list 188ms conn=84e01a55…5173 id=af2efd6c…434f
Apr 29 00:00:15 pi node[153599]: 2026-04-29T00:00:15.790-04:00 [ws] ⇄ res ✓ node.list 73ms conn=84e01a55…5173 id=642e25b6…5424
Apr 29 00:01:24 pi node[153599]: 2026-04-29T00:01:24.175-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavail

fallen trailBOT Apr 29, 2026, 4:03 AM

#

This doesn’t look like Discord “dropping” from the snippet — it looks more like the gateway/session pipeline is getting jammed.

The big clues:

chat.history and models.list taking ~159s
node.list taking 77s
stuck session ... discord:direct:803303300048093194 state=processing
queueDepth=1

So Discord may briefly connect, but the gateway is slow/stuck enough that messages become inconsistent.

Can you paste the output of:

openclaw --version
openclaw status --all

#

openclaw gateway status
openclaw doctor
openclaw channels status --probe

Then restart once after doctor:

openclaw gateway restart

If the stuck-session line comes back after restart, paste the next log chunk around the first stuck session plus any nearby discord, error, disconnect, or model/provider errors.

Docs for the exact triage ladder: https://docs.openclaw.ai/help/troubleshooting and https://docs.openclaw.ai/channels/troubleshooting 🦐

serene cypress Apr 29, 2026, 4:12 AM

#

│ Version │ 2026.4.26
│ OS │ linux 6.12.75+rpt-rpi-v8 (arm64)
│ Node │ 22.22.2
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale exposure │ off
│ Channel │ stable (default)
│ Update │ pnpm · up to date · npm latest 2026.4.26
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout)
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · running (pid 153599, state active)
│ Node service │ systemd not installed
│ Agents │ 1 total · 0 bootstrapping · 1 active · 4 sessions
│ Secrets │ none

│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

Agents
┌────────────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store
│ main │ ABSENT │ 4 │ just now │ ~/.openclaw/agents/main/sessions/sessions.json

#

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/openclaw/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

Gateway last log line:
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
! Port 18789
Port 18789 is already in use.

pid 153599 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 43 eligible · 0 missing · /home/openclaw/.openclaw/workspace
✓ Plugin compatibility (none)

fallen trailBOT Apr 29, 2026, 4:13 AM

#

Yeah — this confirms the issue is below Discord:

Gateway service = running but Gateway = unreachable (timeout)

So the systemd process exists, but the CLI can’t get a timely RPC response from ws://127.0.0.1:18789. That matches your earlier logs where gateway RPCs took 77–159s and sessions got stuck.

I’d do this next:

openclaw gateway restart
sleep 10
openclaw gateway status --deep
openclaw channels status --probe

If it still says unreachable, grab the service/log context:

#

journalctl --user -u openclaw-gateway.service -n 250 --no-pager
openclaw logs --tail 250
ss -ltnp | grep 18789
ps -p 153599 -o pid,etime,stat,%cpu,%mem,cmd

What I’m looking for: port mismatch, duplicate gateway, event-loop starvation, model/provider call hanging, or service launched from a stale install.

If gateway status --deep reports a config/service mismatch, run:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart

#

Docs: https://docs.openclaw.ai/help/troubleshooting / https://docs.openclaw.ai/gateway/troubleshooting

#

That systemctl --user unavailable is important. It means you’re checking/managing the gateway from a shell that doesn’t have the openclaw user’s systemd user bus, so restart/status can get weird. Also don’t start another gateway — port 18789 already has one.

Try from the Pi:

sudo loginctl enable-linger openclaw
sudo systemctl start user@$(id -u openclaw).service

sudo -iu openclaw
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus

systemctl --user status openclaw-gateway.service
openclaw gateway restart
sleep 10
openclaw gateway status --deep

#

openclaw channels status --probe

If it still times out after that, paste:

openclaw logs --tail 250
sudo journalctl _PID=153599 -n 250 --no-pager
ps -p 153599 -o pid,etime,stat,%cpu,%mem,cmd

My read: Discord isn’t the root failure yet — the gateway process is alive on the port but not responding reliably. We need the post-restart logs to see what’s wedging it.

serene cypress Apr 29, 2026, 4:15 AM

#

before I try that, I had previously been doing "sudo openclaw update" could that be part of the problem?

fallen trailBOT Apr 29, 2026, 4:15 AM

#

Yes — that could absolutely be part of it.

sudo openclaw update runs as root, not as the openclaw user. That can cause:

root-owned files under /home/openclaw/.openclaw
root’s npm/pnpm/global OpenClaw being updated instead of the user’s
systemd user-service metadata getting out of sync
commands using /root/.openclaw vs /home/openclaw/.openclaw

From now on, update as the service user:

sudo -iu openclaw
openclaw update

Before changing ownership, check for damage:

#

sudo find /home/openclaw/.openclaw -maxdepth 3 -not -user openclaw -printf '%u:%g %p\n' | head -50
sudo -iu openclaw bash -lc 'whoami; which openclaw; openclaw --version; openclaw update status'
sudo bash -lc 'whoami; which openclaw; openclaw --version'

If that first command shows root-owned files under /home/openclaw/.openclaw, that’s suspicious and likely needs repair.

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

serene cypress Apr 29, 2026, 4:17 AM

#

openclaw@pi:~$ sudo find /home/openclaw/.openclaw -maxdepth 3 -not -user openclaw -printf '%u:%g %p\n' | head -50
sudo -iu openclaw bash -lc 'whoami; which openclaw; openclaw --version; openclaw update status'
sudo bash -lc 'whoami; which openclaw; openclaw --version'
[sudo] password for openclaw:
openclaw
/usr/local/bin/openclaw
OpenClaw 2026.4.26 (be8c246)
OpenClaw update status

┌──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.26

root
/usr/local/bin/openclaw
OpenClaw 2026.4.26 (be8c246)

fallen trailBOT Apr 29, 2026, 4:17 AM

#

Good news: that output doesn’t show root-owned files in /home/openclaw/.openclaw at depth 3, and both root/user see the same 2026.4.26, so sudo openclaw update probably didn’t corrupt the install this time.

Still: avoid it going forward. Use:

sudo -iu openclaw
openclaw update

Now I’d focus back on the broken user-systemd/gateway hang. From openclaw@pi:

sudo loginctl enable-linger openclaw
sudo systemctl start user@$(id -u openclaw).service

export XDG_RUNTIME_DIR=/run/user/$(id -u)

#

export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus

systemctl --user status openclaw-gateway.service
openclaw gateway restart
sleep 10
openclaw gateway status --deep

If it still times out, paste:

openclaw logs --tail 250
ps -p 153599 -o pid,etime,stat,%cpu,%mem,cmd

serene cypress Apr 29, 2026, 4:23 AM

#

openclaw@pi:~ $ openclaw logs --tail 250
ps -p 153599 -o pid,etime,stat,%cpu,%mem,cmd
error: unknown option '--tail'
PID ELAPSED STAT %CPU %MEM CMD

fallen trailBOT Apr 29, 2026, 4:24 AM

#

My bad — that option should be --limit, not --tail.

Also, ps returning only the header means PID 153599 is gone now, so the gateway either restarted or exited. Grab the current state/PID:

openclaw gateway status --deep
openclaw logs --limit 250 --plain
pgrep -af 'openclaw.*gateway|node.*openclaw'
ss -ltnp | grep 18789

If pgrep shows a new PID, run:

ps -p <NEW_PID> -o pid,etime,stat,%cpu,%mem,cmd

#

And if systemd is managing it, also:

journalctl --user -u openclaw-gateway.service -n 250 --no-pager

The key thing now is whether the gateway is exiting/restarting or alive but wedged.

serene cypress Apr 29, 2026, 4:25 AM

#

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=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 178664, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 178664 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789

fallen trailBOT Apr 29, 2026, 4:25 AM

#

Good, now we know it’s alive but not answering the WebSocket probe. That’s a wedged/saturated gateway, not a port/config mismatch.

Please grab the current logs + process stats:

openclaw logs --limit 250 --plain
ps -p 178664 -o pid,etime,stat,%cpu,%mem,rss,vsz,cmd
journalctl --user -u openclaw-gateway.service -n 250 --no-pager

If openclaw logs also times out, bypass RPC and read the file directly:

tail -250 /tmp/openclaw/openclaw-2026-04-29.log

Also useful on a Pi:

#

free -h
df -h
top -b -n1 | head -40

The likely next branch:

high CPU / memory / swap → gateway is starved
logs show stuck session/model/tool call → session pipeline is wedged
logs show Discord reconnect/auth errors → then we chase Discord specifically

Right now the gateway health has to be fixed before Discord will be reliable.

serene cypress Apr 29, 2026, 4:26 AM

#

d before connect conn=2f01f9d9-97dd-4423-9125-aaa264de9187 peer=127.0.0.1:42994->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
2026-04-29T04:21:17.024Z error Error: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback
2026-04-29T04:22:35.124Z info browser/server {"subsystem":"browser/server"} Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-29T04:22:38.195Z info gateway {"subsystem":"gateway"} gateway ready
2026-04-29T04:22:38.212Z info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":3600000} heartbeat: started
2026-04-29T04:22:39.732Z warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":3,"host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":37668,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:37668->127.0.0.1:18789"} closed before connect conn=01a2d77b-5a91-44a7-90b5-32c86bd78abb peer=127.0.0.1:37668->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
2026-04-29T04:22:39.849Z info cron {"module":"cron","storePath":"/home/openclaw/.openclaw/cron/cron.json"} {"enabled":true,"jobs":23,"nextWakeAtMs":1777437000000} cron: started

#

2026-04-29T04:22:39.871Z info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=4564ed18-6bff-465e-a6d0-da214cb890e3 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.26
2026-04-29T04:22:43.040Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.subscribe 1210ms conn=4564ed18…90e3 id=ec18119e…82c4
2026-04-29T04:22:43.056Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ agent.identity.get 1223ms conn=4564ed18…90e3 id=f805cbc3…4a70
2026-04-29T04:22:43.067Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ agents.list 1233ms conn=4564ed18…90e3 id=d1b0decf…be83
2026-04-29T04:22:43.077Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 1240ms cached=true conn=4564ed18…90e3 id=64e1ff01…c7c5
2026-04-29T04:22:44.672Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 2825ms conn=4564ed18…90e3 id=4bdbb965…f008
2026-04-29T04:22:47.312Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 5462ms conn=4564ed18…90e3 id=8c387113…1ff3
2026-04-29T04:22:48.688Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 6851ms conn=4564ed18…90e3 id=2ff10c2b…a531
2026-04-29T04:22:48.699Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 6860ms conn=4564ed18…90e3 id=a60560ab…4261

#

2026-04-29T04:24:52.418Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 130579ms conn=4564ed18…90e3 id=afd7e0c5…b469
2026-04-29T04:24:52.450Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ models.list 130603ms conn=4564ed18…90e3 id=45f60242…9c29
2026-04-29T04:24:55.310Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 67109ms conn=4564ed18…90e3 id=8308f603…854a
2026-04-29T04:24:55.335Z warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":5,"host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":34062,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:34062->127.0.0.1:18789"} closed before connect conn=e61b5ed2-4973-48f7-b6d6-613ab59a4dc4 peer=127.0.0.1:34062->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
151440 journalctl --user -u openclaw-gateway -f
178664 openclaw-gateway
179439 systemctl --user status openclaw-gateway.service
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=178664,fd=25))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=178664,fd=26))

fallen trailBOT Apr 29, 2026, 4:26 AM

#

That snippet shows the restart succeeded:

gateway ready
heartbeat: started
cron: started

The gateway timeout after 30000ms was from before that restart. The closed before connect ... code=1006 right after startup may just be the probe/CLI giving up early, not necessarily the root error.

Next, wait ~20 seconds and run:

openclaw gateway status --deep
openclaw channels status --probe

If it still times out, paste the next 100–200 lines after cron: started, plus:

#

tail -250 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei 'discord|error|warn|timeout|stuck|fatal|oom|heap|memory'
ps -p 178664 -o pid,etime,stat,%cpu,%mem,rss,vsz,cmd
free -h

Right now we need to see whether Discord starts and then disconnects, or whether the gateway wedges immediately after startup.

#

This is better than before: RPC is responding again, but it’s slow for a fresh gateway — commands.list/node.list/device.pair.list taking ~5–7s is not great, especially on a Pi.

Now we need the Discord/runtime part. Please run:

openclaw channels status --probe
tail -250 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei 'discord|channel|error|warn|timeout|stuck|fatal|oom|heap|memory'
ps -p 178664 -o pid,etime,stat,%cpu,%mem,rss,vsz,cmd
free -h

If the dashboard/browser tab is open, also close it temporarily and retest Discord — the Control UI is already issuing several expensive startup RPCs, and on a Pi that can make startup races much worse.

#

Yep, this is the smoking gun:

chat.history 130579ms
models.list 130603ms
node.list 67109ms

That’s the Control UI/WebChat connection making startup RPCs that are taking 1–2 minutes. On a Pi, that can absolutely starve the gateway enough that Discord looks like it’s dropping.

Do this test cleanly:

Close the dashboard/control UI tab completely
Restart gateway:

openclaw gateway restart
sleep 30

#

openclaw channels status --probe

DM/post to Discord without opening the dashboard.

Also run the repair pass, especially since you came through 4.25/4.26:

openclaw doctor --fix
openclaw gateway restart

If it still wedges, please paste the unfiltered log lines from 04:22:39 through 04:24:55 — not just grep output:

#

awk '$0 >= "2026-04-29T04:22:39" && $0 <= "2026-04-29T04:24:56"' /tmp/openclaw/openclaw-2026-04-29.log

I’m looking for what was blocking those RPCs for 130s.

serene cypress Apr 29, 2026, 4:27 AM

#

i still have discord disabled

fallen trailBOT Apr 29, 2026, 4:27 AM

#

Ah, perfect context — then we can ignore Discord for the moment. The gateway is getting bogged down even with Discord disabled, so Discord was a symptom, not the cause.

Next clean test:

# close dashboard/control UI first
openclaw doctor --fix
openclaw gateway restart
sleep 30
openclaw gateway status --deep
openclaw health --verbose

If that’s healthy, then re-enable Discord and probe it.

If it’s still slow/unreachable with Discord disabled, paste:

#

awk '$0 >= "2026-04-29T04:22:39" && $0 <= "2026-04-29T04:24:56"' /tmp/openclaw/openclaw-2026-04-29.log
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o pid,etime,stat,%cpu,%mem,rss,vsz,cmd
free -h
df -h /home /tmp

Given those 130s chat.history / models.list responses, I’m suspicious of slow Pi I/O, oversized/stuck session history, or a startup task blocking the event loop. Doctor may catch stale locks/session repair from the 4.24–4.26 path.

serene cypress Apr 29, 2026, 4:30 AM

#

Apr 29 00:28:14 pi node[180274]: 2026-04-29T00:28:14.852-04:00 [ws] webchat connected conn=f69668bc-f41e-4734-995d-b5a0cd3a0875 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.26
Apr 29 00:28:17 pi node[180274]: 2026-04-29T00:28:17.843-04:00 [ws] ⇄ res ✓ sessions.subscribe 990ms conn=f69668bc…0875 id=c83c9f2d…d98e
Apr 29 00:28:17 pi node[180274]: 2026-04-29T00:28:17.859-04:00 [ws] ⇄ res ✓ agent.identity.get 1004ms conn=f69668bc…0875 id=cca17c29…7eb8
Apr 29 00:28:17 pi node[180274]: 2026-04-29T00:28:17.868-04:00 [ws] ⇄ res ✓ agents.list 1015ms conn=f69668bc…0875 id=6404cf8b…897c
Apr 29 00:28:17 pi node[180274]: 2026-04-29T00:28:17.881-04:00 [ws] ⇄ res ✓ health 1024ms cached=true conn=f69668bc…0875 id=5916edc5…546d
Apr 29 00:28:19 pi node[180274]: 2026-04-29T00:28:19.523-04:00 [ws] ⇄ res ✗ chat.history 2665ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=f69668bc…0875 id=1b8443bf…7d73
Apr 29 00:28:19 pi node[180274]: 2026-04-29T00:28:19.589-04:00 [ws] ⇄ res ✓ sessions.list 2729ms conn=f69668bc…0875 id=6523328b…6410
Apr 29 00:28:19 pi node[180274]: 2026-04-29T00:28:19.599-04:00 [ws] ⇄ res ✗ models.list 2736ms errorCode=UNAVAILABLE errorMessage=models.list unavailable during gateway startup conn=f69668bc…0875 id=73123275…cbba
Apr 29 00:28:22 pi node[180274]: 2026-04-29T00:28:22.743-04:00 [ws] ⇄ res ✓ commands.list 5879ms conn=f69668bc…0875 id=fb27b274…1955
Apr 29 00:28:23 pi node[180274]: 2026-04-29T00:28:23.816-04:00 [ws] ⇄ res ✗ chat.history 1ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=f69668bc…0875 id=1dc7dc8b…f0b8
Apr 29 00:30:01 pi node[180274]: 2026-04-29T00:30:01.243-04:00 [ws] ⇄ res ✗ chat.history 1ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=f69668bc…0875 id=eac0b112…2879
Apr 29 00:30:01 pi node[180274]: 2026-04-29T00:30:01.259-04:00 [ws] ⇄ res ✓ node.list 104402ms conn=f69668bc…0875 id=faf41dbc…35a3

#

Apr 29 00:30:01 pi node[180274]: 2026-04-29T00:30:01.271-04:00 [ws] ⇄ res ✓ device.pair.list 104414ms conn=f69668bc…0875 id=142656ea…5e8c
Apr 29 00:30:01 pi node[180274]: 2026-04-29T00:30:01.305-04:00 [ws] closed before connect conn=d21d3fe8-f06d-475b-b3b1-58e45dda2f31 peer=127.0.0.1:45952->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a

fallen trailBOT Apr 29, 2026, 4:32 AM

#

Got it. This is useful: Discord disabled means Discord is not the blocker.

The important part is:

chat.history unavailable during gateway startup
models.list unavailable during gateway startup
node.list 104402ms

So the gateway is still stuck in startup/sidecar initialization after ~2 minutes. chat.history/models.list being rejected is expected during startup; node.list taking 104s is not.

Also: the Control UI is still connected in this log (webchat connected). For the next test, close that tab completely so it stops hammering startup RPCs.

Please run this diagnostic trace:

systemctl --user set-environment OPENCLAW_GATEWAY_STARTUP_TRACE=1

#

openclaw gateway restart
sleep 45
tail -300 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei 'startup trace|starting channels|sidecars|gateway ready|plugin|channel|error|warn'

If it still never reaches gateway ready, do one isolation test:

systemctl --user set-environment OPENCLAW_SKIP_CHANNELS=1
openclaw gateway restart
sleep 45
openclaw gateway status --deep
tail -200 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei 'startup trace|sidecars|gateway ready|error|warn'

Then unset the temporary skip flag:

#

systemctl --user unset-environment OPENCLAW_SKIP_CHANNELS

If OPENCLAW_SKIP_CHANNELS=1 makes startup healthy, one enabled channel/sidecar is blocking. If it’s still slow, we look at plugin services/session locks/filesystem next.

#

Yep — device.pair.list 104414ms confirms it’s not just node.list; even tiny local state reads are getting delayed ~104s. That strongly points to startup blocking/event-loop starvation or very slow filesystem I/O, not Discord.

Do the startup trace next; it should tell us which phase owns that 104s:

systemctl --user set-environment OPENCLAW_GATEWAY_STARTUP_TRACE=1
openclaw gateway restart
sleep 45
tail -300 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei 'startup trace|starting channels|sidecars|gateway ready|plugin|channel|error|warn'

And please make sure the dashboard tab is closed while doing this. The dashboard is exposing the symptom, but the trace should reveal the blocker.

#Discord Channel Dropping