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

open   by a73x

Labels: backlog

[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.