Stale daemon state file with reused PID causes update install to signal wrong process and double-restart daemon

[Rinse12]

Bug

isPidAlive() in src/common-utils/daemon-state.ts only checks process.kill(pid, 0). A PID being alive does not prove the process is the bitsocial daemon that wrote the state file (classic stale-pidfile / PID-reuse hazard).

Observed failure

A daemon previously ran inside a Docker container that mounted the host's bitsocial data dir. Inside the container's PID namespace it was PID 8, so it wrote .daemon_states/8-daemon.state into the shared dir. The container went away without graceful shutdown, leaving the file behind. On the host, PID 8 is a kernel thread — so the stale state passed the liveness check forever.

bitsocial update install then:

1. Sent SIGINT to PID 8 (an unrelated process — could be any innocent process on a different day)
2. Restarted 2 daemons with identical args on the same port; the second died with EADDRINUSE
3. Falsely reported "Daemon started (port 9138)" for the second spawn because waitUntilUsed saw the first daemon's port

Fix plan

• Record the OS-reported process start time (procStartTime) in the daemon state file at write time
• When checking aliveness, compare the current start time of that PID against the recorded one — mismatch means the PID was reused and the state is stale
• For legacy state files without the field, fall back to a command-line check (/proc/<pid>/cmdline / ps -o args= must reference bitsocial); kernel threads have an empty cmdline so they are correctly treated as stale
• Regression tests reproducing the PID-reuse scenario

[Rinse12]

Progress

Bug reproduced in a regression test before fixing: test/common-utils/daemon-state.test.ts — a legacy-format state file (byte-for-byte like the one left on the affected host) whose PID belongs to an alive but unrelated process (sleep, standing in for the kernel thread). On unfixed code, getAliveDaemonStates() returned it as a running daemon (test failed: 1 failed | 8 passed).

Fix implemented in src/common-utils/daemon-state.ts, two layers:

1. writeDaemonState now records the OS-reported process start time (procStartTime, from /proc/<pid>/stat field 22, ps -o lstart= fallback). Aliveness checks compare it — a reused PID has a different start time.
2. Legacy state files without the field fall back to a cmdline heuristic: the process command line must reference bitsocial. Kernel threads have an empty cmdline, so the original stale file is correctly pruned.

3 new tests: PID reuse with legacy file (the original regression), procStartTime mismatch, and a legacy file for a genuine daemon-like process that must be kept. All 11 daemon-state tests pass; full suite running now.

[Rinse12]

Fix committed on branch fix/daemon-state-pid-reuse (fe3609e). Full test suite green (244 passed, 1 skipped). The stale state file was also removed manually from the affected host, so it's no longer at risk even before this ships.