can't reach dashboard | Friends of the Crustacean 🦞🤝 | Page 1

orchid hemlock May 14, 2026, 9:32 PM

#

I updated to 2025.5.12 and rebooted my raspberry pi. When I run sudo -u openclaw -H openclaw dashboard I I get:

momo@peach:~ $ sudo -u openclaw -H openclaw dashboard
Config warnings:

plugins.entries.memory-lancedb: plugin not installed: memory-lancedb — install the official external plugin with: openclaw plugins install @openclaw/memory-lancedb

🦞 OpenClaw 2026.5.12 (f066dd2)
Finally, a use for that always-on Mac Mini under your desk.

│
◇ Config warnings ──────────────────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.memory-lancedb: plugin not installed: memory-lancedb — install │
│ the official external plugin with: openclaw plugins install │
│ @openclaw/memory-lancedb │
│ │
├────────────────────────────────────────────────────────────────────────────────────╯
Dashboard URL: http://127.0.0.1:18789/
Token auto-auth included in browser/clipboard URL.
Copy to clipboard unavailable.
No GUI detected. Open from your computer:
ssh -N -L 18789:127.0.0.1:18789 openclaw@<host>
Then open:
http://localhost:18789/
Docs:
https://docs.openclaw.ai/gateway/remote
https://docs.openclaw.ai/web/control-ui
Token auto-auth not delivered. Append your gateway token (from OPENCLAW_GATEWAY_TOKEN or gateway.auth.token) as a URL fragment with key token to authenticate.

I've made the SSH connection on my desktop:
C:\Users\Lukas>ssh -i "C:\Users\Lukas\Dropbox\Code\KEYS\raspberrypi-openssh" -N -L 18789:127.0.0.1:18789 momo@192.168.178.41
channel 2: open failed: connect failed: Connection refused

And I'm on the same network. this all used to work before, but now in my browser 127.0.0.1:18789 gives me "This site can’t be reached
The connection was reset."

delicate belfryBOT May 14, 2026, 9:32 PM

#

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

stark bayBOT May 14, 2026, 9:32 PM

#

That memory-lancedb warning is probably unrelated — annoying, but it shouldn’t stop the dashboard from binding.

The important bit is this:

channel 2: open failed: connect failed: Connection refused

That means SSH reached the Pi, but on the Pi side nothing was accepting connections on 127.0.0.1:18789 at that moment. So I’d check the gateway itself first, as the same openclaw user:

sudo -u openclaw -H openclaw gateway status
sudo -u openclaw -H openclaw status --all
sudo ss -ltnp | grep 18789 || true

If nothing is listening on 18789, restart the gateway:

#

sudo -u openclaw -H openclaw gateway restart

Then retry the tunnel from Windows and keep that SSH command running:

ssh -i "C:\Users\Lukas\Dropbox\Code\KEYS\raspberrypi-openssh" -N -L 18789:127.0.0.1:18789 momo@192.168.178.41

Then open http://127.0.0.1:18789/ or http://localhost:18789/ on the desktop. Without a working tunnel, that address is just your Windows machine’s own localhost, not the Pi.

If gateway status says it’s running but ss still shows no listener, paste the openclaw gateway status + openclaw status --all output. Docs for this path are here: https://docs.openclaw.ai/gateway/remote and https://docs.openclaw.ai/web/control-ui

orchid hemlock May 14, 2026, 9:39 PM

#

momo@peach:~ $ sudo -u openclaw -H openclaw gateway status
Config warnings:

plugins.entries.memory-lancedb: plugin not installed: memory-lancedb — install the official external plugin with: openclaw plugins install @openclaw/memory-lancedb

🦞 OpenClaw 2026.5.12 (f066dd2)
I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

│
◇
Service: systemd user (disabled)
File logs: /tmp/openclaw/openclaw-2026-05-14.log
Command: /usr/bin/node /opt/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: 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

I use a hardened setup on my raspberry pi, it has worked before despite gateway being 'unavailable' like this.

openclaw status all:

Dashboard │ http://127.0.0.1:18789/
Channel │ stable (default)
Update │ pnpm
Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable
│ (connect ECONNREFUSED 127.0.0.1:18789)
Gateway self │ unknown
Gateway service │ systemd user installed · disabled · unknown (Failed to connect
│ to system scope bus via machine transport: Permission denied
│ Failed to get properties: Transport endpoint is not connected)
Node service │ systemd user not installed

stark bayBOT May 14, 2026, 9:39 PM

#

Yep — this output confirms the tunnel/browser problem is downstream of the gateway not listening.

gateway dashboard only prints/opens the Control UI URL; it does not start the gateway. And this line is the smoking claw:

Gateway · unreachable (connect ECONNREFUSED 127.0.0.1:18789)

The hardened setup may explain the ugly systemd status error, but it doesn’t explain ECONNREFUSED: nothing is bound to port 18789.

Try starting it explicitly as the openclaw user:

sudo -iu openclaw
openclaw gateway

#

Leave that running, then from your Windows desktop retry the SSH tunnel. If the dashboard works while openclaw gateway is running foreground, the issue is purely the service/user-systemd side.

For the service path, because you’re using a dedicated openclaw user on a headless Pi, I’d check lingering + the user unit from inside a real login shell for that user:

sudo loginctl enable-linger openclaw
sudo -iu openclaw
systemctl --user daemon-reload
systemctl --user enable --now openclaw-gateway.service
systemctl --user status openclaw-gateway.service
journalctl --user -u openclaw-gateway.service -n 100 --no-pager

If systemctl --user still fails under sudo -iu openclaw, your hardening is blocking the user systemd bus/session. In that case either adjust the hardening to allow the openclaw user’s user-manager, or run OpenClaw via a system service/custom supervisor instead of the default systemd user unit.

Docs refs: https://docs.openclaw.ai/platforms/raspberry-pi and https://docs.openclaw.ai/gateway/remote

orchid hemlock May 14, 2026, 9:45 PM

#

I'm not sure what -iu openclaw does but this is what happens when I try to open the gateway with sudo -u openclaw -H openclaw gateway:

momo@peach:~ $ sudo -iu openclaw
openclaw gateway
This account is currently not available.

🦞 OpenClaw 2026.5.12 (f066dd2) — Greetings, Professor Falken

│
◇
22:40:10 [gateway] loading configuration…
22:40:10 [gateway] resolving authentication…
22:40:10 Missing config. Run openclaw setup or set gateway.mode=local (or pass --allow-unconfigured).
momo@peach:~ $ sudo -u openclaw -H openclaw gateway
Config warnings:

plugins.entries.memory-lancedb: plugin not installed: memory-lancedb — install the official external plugin with: openclaw plugins install @openclaw/memory-lancedb

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

│
◇
22:40:41 [gateway] loading configuration…
22:40:41 [gateway] resolving authentication…
22:40:41 [gateway] starting...
22:40:45 [gateway] auto-enabled plugins for this runtime without writing config:

codex agent runtime configured, enabled automatically.
22:40:46 [gateway] starting HTTP server...
22:40:46 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
22:40:47 [gateway] agent model: openai-codex/gpt-5.4 (thinking=medium, fast=off)
22:40:47 [gateway] http server listening (3 plugins: browser, clawvault, discord; 5.1s)
22:40:47 [gateway] log file: /tmp/openclaw/openclaw-2026-05-14.log
22:40:47 [gateway] starting channels and sidecars...
22:40:47 [hooks] loaded 5 internal hook handlers
22:40:47 [discord] [default] starting provider
22:40:48 [plugins] [clawvault] service started — vault=/var/lib/openclaw/clawvault
22:40:49 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
22:40:49 [gateway] ready
22:40:49 [heartbeat] started
22:40:49 [gateway] signal SIGTERM received
22:40:49 [gateway] received SIGTERM; shutting down

stark bayBOT May 14, 2026, 9:45 PM

#

Ah, that explains two separate things.

sudo -iu openclaw means “become openclaw as a login shell”. Your openclaw account has a disabled login shell (This account is currently not available), which is normal for service users. So don’t use -iu on that setup.

Use this shape instead:

sudo -u openclaw -H bash -lc 'openclaw gateway --port 18789'

The weird part is this:

[gateway] ready
[gateway] signal SIGTERM received

#

So OpenClaw does start successfully, then something immediately tells it to stop. That is why the tunnel gets connection refused.

Next I’d check who/what is stopping it:

sudo -u openclaw -H bash -lc 'echo HOME=$HOME; id; openclaw gateway status'
sudo journalctl --since "10 minutes ago" --no-pager | grep -iE 'openclaw|sigterm|kill|oom|systemd|sudo'
tail -n 120 /tmp/openclaw/openclaw-2026-05-14.log

Also, because this is a service account with no login shell, the default systemd user service is probably a bad fit unless your hardening explicitly supports user managers for openclaw. You likely want one of these:

keep using the service account, but run it as a system service with User=openclaw; or
relax the hardening enough for openclaw’s systemd user service + lingering to work; or
run OpenClaw under your normal momo user instead.

My recommendation for a hardened headless Pi is option 1: system service with User=openclaw. The current state looks like the user-service path can’t manage itself reliably.

orchid hemlock May 14, 2026, 9:53 PM

#

May 14 22:47:41 peach openclaw[5910]: 2026-05-14T22:47:41.060+01:00 Missing config. Run openclaw setup or set gateway.mode=local (or pass --allow-unconfigured).
May 14 22:47:41 peach systemd[1]: openclaw.service: Main process exited, code=exited, status=78/CONFIG
May 14 22:47:41 peach systemd[1]: openclaw.service: Failed with result 'exit-code'.
May 14 22:47:41 peach systemd[1]: openclaw.service: Consumed 1.363s CPU time.
May 14 22:47:46 peach systemd[1]: openclaw.service: Scheduled restart job, restart counter is at 232.
May 14 22:47:46 peach systemd[1]: Starting openclaw.service - OpenClaw Gateway...
May 14 22:47:46 peach systemd[1]: Started openclaw.service - OpenClaw Gateway.
May 14 22:47:47 peach openclaw[5925]: 2026-05-14T22:47:47.246+01:00 [gateway] loading configuration…
May 14 22:47:47 peach openclaw[5925]: 2026-05-14T22:47:47.270+01:00 [gateway] force: no listeners on port 18789
May 14 22:47:47 peach openclaw[5925]: 2026-05-14T22:47:47.281+01:00 [gateway] resolving authentication…
May 14 22:47:47 peach openclaw[5925]: 2026-05-14T22:47:47.283+01:00 Missing config. Run `ope

the tail command gives me:

{"0":"{"subsystem":"gateway/shutdown"}","1":"shutdown completed cleanly in 338ms","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway/shutdown"}","parentNames":["openclaw"],"date":"2026-05-14T21:46:07.720Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/opt/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/opt/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-14T22:46:07.721+01:00","hostname":"peach","message":"shutdown completed cleanly in 338ms"}

stark bayBOT May 14, 2026, 9:54 PM

#

Found it. You have a system-level service named openclaw.service in a restart loop, and it’s starting OpenClaw with the wrong config/home context:

systemd[1]: openclaw.service ... restart counter is at 232
openclaw[...] Missing config

That’s separate from the OpenClaw default systemd --user unit. Your manual command works because sudo -u openclaw -H ... gives it /home/openclaw and finds ~/.openclaw/openclaw.json; the system service likely does not.

First stop the broken restart loop so it stops fighting you:

sudo systemctl stop openclaw.service
sudo systemctl disable openclaw.service

Then inspect what it was doing:

#

sudo systemctl cat openclaw.service

If you want to keep the hardened system service approach, the unit should explicitly run as the openclaw user and set the right home/env. Something like:

[Service]
User=openclaw
Group=openclaw
Environment=HOME=/home/openclaw
WorkingDirectory=/home/openclaw
ExecStart=/usr/bin/node /opt/openclaw/dist/index.js gateway --port 18789
Restart=always
RestartSec=5

#

After editing/replacing the unit:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw.service
sudo systemctl status openclaw.service
sudo ss -ltnp | grep 18789 || true

If ss shows 127.0.0.1:18789 listening, your Windows SSH tunnel should work again.

One more important clue: the force: no listeners on port 18789 line suggests that system service may be starting with a “force/kill existing listener” mode. That could explain why your foreground gateway got SIGTERM right after becoming ready. So I’d definitely inspect sudo systemctl cat openclaw.service before re-enabling it.

orchid hemlock May 14, 2026, 10:00 PM

#

momo@peach:~ $ sudo systemctl cat openclaw.service
/etc/systemd/system/openclaw.service,
[Unit]
Description=OpenClaw Gateway
After=network-online.target
Wants=network-online.target

Optional but strong safety check:,
Refuse to start if onboarding/config was never completed,
ConditionPathExists=/var/lib/openclaw/.openclaw/openclaw.json,
[Service]
Type=simple
User=openclaw
Group=openclaw

─,
Sanity guards,
─,
Ensure Node.js exists and is callable (fail fast if missing),
ExecStartPre=/usr/bin/node --version

Refuse to start if the canonical OpenClaw binary is missing,
or not executable (prevents silent boot failures),
ExecStartPre=/usr/bin/test -x /usr/local/bin/openclaw

─,
Canonical execution path,
MUST match the command validated manually,
─,
ExecStart=/usr/local/bin/openclaw gateway --force

Runtime working directory (state + config live here),
WorkingDirectory=/var/lib/openclaw

Environment,
Environment=NODE_ENV=production
Environment=OPENCLAW_STATE_DIR=/var/lib/openclaw

Restart policy,
Restart=on-failure
RestartSec=5

─,
Logging (explicit journald routing),
─,
StandardOutput=journal
StandardError=journal

─,
Hardening,
─,
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/openclaw
RestrictNamespaces=true
RestrictRealtime=true
LockPersonality=true

Optional resource ceilings (recommended on Pi-class hardware),
MemoryMax=4G,
CPUQuota=200%,
[Install]
WantedBy=multi-user.target

/var/lib/openclaw is correct path afaik

stark bayBOT May 14, 2026, 10:01 PM

#

/var/lib/openclaw can be the right home/work dir, but your env points OpenClaw at the wrong state dir.

Your unit has:

Environment=OPENCLAW_STATE_DIR=/var/lib/openclaw
ConditionPathExists=/var/lib/openclaw/.openclaw/openclaw.json

With OPENCLAW_STATE_DIR=/var/lib/openclaw, OpenClaw looks for:

/var/lib/openclaw/openclaw.json

…but your condition says the config is actually here:

#

/var/lib/openclaw/.openclaw/openclaw.json

So the fix is probably one of these two shapes:

Environment=HOME=/var/lib/openclaw
Environment=OPENCLAW_STATE_DIR=/var/lib/openclaw/.openclaw
Environment=OPENCLAW_CONFIG_PATH=/var/lib/openclaw/.openclaw/openclaw.json
WorkingDirectory=/var/lib/openclaw
ExecStart=/usr/local/bin/openclaw gateway --port 18789

Also: I’d remove --force from the service. That can kill an already-running gateway on the same port, which matches the SIGTERM you saw when testing manually.

Before editing, verify the actual file location:

#

sudo -u openclaw test -f /var/lib/openclaw/.openclaw/openclaw.json && echo yes
sudo -u openclaw test -f /var/lib/openclaw/openclaw.json && echo root-json-yes

Then update the unit, reload, restart:

sudo systemctl edit --full openclaw.service
sudo systemctl daemon-reload
sudo systemctl restart openclaw.service
sudo systemctl status openclaw.service
sudo ss -ltnp | grep 18789 || true

One nit: the prose lines in that unit should be comments starting with #. systemd usually ignores unknown lines with warnings, but I’d clean them up while you’re in there.

orchid hemlock May 15, 2026, 1:29 AM

#

Okay, the agent is back up after making the Environment= changes to the openclaw.service. I am able to talk to it.

However on the dashboard, I don't see any of the cron jobs I used to have. There also doesn't seem to be any access to old chat logs - only chats that I've started since the update are showing up on the dashboard. My cron job file is at /var/lib/openclaw/cron/jobs.json. These previously showed up in the dashboard just fine

stark bayBOT May 15, 2026, 1:30 AM

#

orchid hemlock Okay, the agent is back up after making the Environment= changes to the openclaw...

That sounds like the gateway is healthy now, but it is looking at a different state/config root than the one that contains your old cron + session data.

Current paths to check:

cron default store is ~/.openclaw/cron/jobs.json, unless cron.store is set
session index default is ~/.openclaw/agents/<agentId>/sessions/sessions.json
transcripts live next to that as <sessionId>.jsonl
if OPENCLAW_STATE_DIR is set, those defaults move under that directory

Since your old cron file is /var/lib/openclaw/cron/jobs.json, either the service should have OPENCLAW_STATE_DIR=/var/lib/openclaw, or your config should explicitly set:

{
  cron: {
    store: "/var/lib/openclaw/cron/jobs.json"
  },

stark bayBOT May 15, 2026, 1:30 AM

#

orchid hemlock Okay, the agent is back up after making the Environment= changes to the openclaw...

  session: {
    store: "/var/lib/openclaw/agents/{agentId}/sessions/sessions.json"
  }
}

First I’d compare what the running service is using:

sudo systemctl show openclaw --property=Environment
sudo -u openclaw -H openclaw config path
sudo -u openclaw -H openclaw config get cron.store
sudo -u openclaw -H openclaw config get session.store
sudo -u openclaw -H openclaw cron list
sudo -u openclaw -H openclaw sessions list

#can't reach dashboard