a daemon whose socket file is deleted can never be reached by path again, and no admin verb reaches it any other way #84

New issue

Open

opened 2026-09-04 13:11:10 +00:00 by a73x · 0 comments

a73x commented

2026-09-04 13:11:10 +00:00

(Migrated from git.a73x.sh)

[claude 2026-09-04] Seen 2026-09-04. The daemon (pid 2562370, 3 days up, upgraded in place
at 11:51) lost /run/user/1000/muxd.sock from disk between 13:21 and 13:45.
It kept running, kept its three sessions, kept LISTENING on the unlinked
inode (ss -xlp still shows the path string), and kept its QUIC arm on UDP
48418. But:

there is no way to give it a path back: serve.adopt only re-stamps the id
of a file already there, and nothing re-binds (grep rebind: nothing);
every mux d admin verb — stop, upgrade, dump, stats — takes --sock only,
so the daemon cannot be stopped, upgraded, or inspected. It can be attached
to over quic://127.0.0.1:48418, or killed with a signal, which "runs
nothing" by design and orphans the ptys.

Meanwhile a second daemon bound the same path (see the auto-start issue),
so ss -xlp shows two LISTEN entries for one path string and only the newer
answers dials. The rule "no socket stealing" held — nothing stole — but the
outcome is the one that rule exists to prevent: sessions stranded on a
daemon nobody can reach.

Options worth weighing: (a) a daemon that notices its path no longer names
its inode (a cheap stat on each accept, or on a timer) re-binds or at least
logs loudly; (b) mux d stop/upgrade/dump accept --quic HOST:PORT --key
like mux a does, so a path-less daemon is still administrable; (c) both.

Migrated from git-collab issue 7e02b9651c3ec8179111b5b5c8b776ac5cc075a7.

Original author: a73x dev@a73x.sh.

[claude 2026-09-04] Seen 2026-09-04. The daemon (pid 2562370, 3 days up, upgraded in place at 11:51) lost `/run/user/1000/muxd.sock` from disk between 13:21 and 13:45. It kept running, kept its three sessions, kept LISTENING on the unlinked inode (`ss -xlp` still shows the path string), and kept its QUIC arm on UDP 48418. But: - there is no way to give it a path back: `serve.adopt` only re-stamps the id of a file already there, and nothing re-binds (grep rebind: nothing); - every `mux d` admin verb — stop, upgrade, dump, stats — takes `--sock` only, so the daemon cannot be stopped, upgraded, or inspected. It can be attached to over `quic://127.0.0.1:48418`, or killed with a signal, which "runs nothing" by design and orphans the ptys. Meanwhile a second daemon bound the same path (see the auto-start issue), so `ss -xlp` shows two LISTEN entries for one path string and only the newer answers dials. The rule "no socket stealing" held — nothing stole — but the outcome is the one that rule exists to prevent: sessions stranded on a daemon nobody can reach. Options worth weighing: (a) a daemon that notices its path no longer names its inode (a cheap stat on each accept, or on a timer) re-binds or at least logs loudly; (b) `mux d stop/upgrade/dump` accept `--quic HOST:PORT --key` like `mux a` does, so a path-less daemon is still administrable; (c) both. --- Migrated from git-collab issue `7e02b9651c3ec8179111b5b5c8b776ac5cc075a7`. Original author: a73x <dev@a73x.sh>.