Closed general

Linux relay: died during 2.0.83->2.0.86 self-update (restart-report spawn ENOENT); plain serve runs on the published default token

John Lauer · 27d ago ·closed by John Lauer

Found 2026-10-14 by a Grok Bot agent on its own Linux computer (container-style install, adom-bridge 2.0.86 at /home/box/.local/bin), reported in its chat and summarized here.

1. Relay never came back after an auto-update (2.0.83 -> 2.0.86)

relay-supervisor.log ends with:

binary updated on disk 2.0.83 -> 2.0.86 — gracefully restarting the relay into it
restarting relay after binary update
restart-report notify failed to spawn: No such file or directory (os error 2)

Neither PID in relay.pid nor relay-supervisor.pid was alive afterwards; last relay.log line 2026-09-02 16:24 UTC. Nothing listened on 8765/8766 for six weeks, and every CLI call returned status: busy "the desktop isn't connected right now ... it reconnects automatically", which is not what was happening. Expected: a failed restart-report spawn must not abort the relaunch; the CLI should say the local relay process is not running (connection refused on 127.0.0.1:8766) instead of "busy, wait and retry".

2. A plain relay serve ignored ~/.adom/relay-token and ran on the default development token

When the agent restarted the relay by hand, it came up on the default dev token, which is published in the docs, while ~/.adom/relay-token existed. On a relay whose WS port listens on 0.0.0.0:8765, anyone who can reach it could drive any desktop that joins. Expected: serve loads ~/.adom/relay-token when present, and refuses (or loudly warns) to start on the published default.

Related: adom/adom-bridge#240 (relay vs mesh visibility).

1 Reply

John Lauer · 26d ago

Handled, in a different way than patching the old relay: Grok Bot's computer now runs Adom Bridge itself (the new Linux build) instead of a stand-alone relay.

What I found on the box:

  • The 2.0.86 relay (serve --supervise-daemon) was running again, on 0.0.0.0:8765 with the published default token.
  • ~/.adom/relay-public-url pointed at a Cloudflare quick tunnel. No tunnel process is running any more, so it wasn't reachable from outside, but it had been published.
  • Nothing connected to it: John's desktops all use gallia's relay and the mesh.

What I did:

  • Stopped the old relay (serve --stop) and updated the box's CLI to 2.1.175 (adom-wiki pkg update).
  • Installed Adom Bridge for Linux (AppImage, private page john/adom-bridge-linux). It's signed in as John by approval link, the token never passed through a chat, and the box is trusted in his mesh as grok-bot-vm-155244935 (mesh round trips 170 to 350 ms).
  • After a reboot: ~/.local/bin/adom-bridge-app-ensure (called from ~/.profile / ~/.bashrc) starts the app if it isn't running. Nothing else on this box restarts processes after a boot.

On your two original points:

  1. Restart-report ENOENT: that's the old-binary path in the watchdog's notice; the relaunch itself already resolves the binary by PATH. The relay going dark for six weeks was a box restart with nothing to bring the watchdog back, which the ensure hook now covers for Adom Bridge.
  2. Default token on a plain serve: since 2.1.170 serve binds 127.0.0.1 by default, and the old relay is gone from this box.

Found and fixed while doing this (2.1.176): the Linux app leaked the AppImage's library paths into child processes, a --version call could start a second copy of the app, a targeted call stopped at the first relay that didn't know the box, and the app reported its OS as Windows.

John Lauer closed this · 26d ago

Log in to reply.