Daemon teardown hardening: process containment + socket lingering + console events #32

Consolidated scope covering every remaining "daemon must die cleanly and not leak state" concern. Expanded during the 2026-04-17 issue consolidation to absorb the SO_LINGER 0 half of the old B5a hardening item.

Checklist

• Process containment via running-process (original Daemon teardown hardening: process containment + socket lingering + console events #32 scope)
  Adopt running-process's ContainedProcessGroup / Containment primitives for spawned subprocesses so child / grandchild process trees die with the daemon. Windows uses Job Objects with kill-on-close semantics; Linux/macOS use process groups with Linux parent-death handling. Symptoms today: orphaned bash.exe, conhost.exe, OpenConsole.exe on Windows after higher-level jobs disappear. Add an integration test that kills the parent fbuild process and asserts child + grandchild cleanup on Windows.

• SO_LINGER 0 on accepted client sockets (was Outstanding work: ledger removal, send_op errors, async API, B5a hardening, espflash native, sector-selective flashing #18 item 4b)
  After a hard kill, dangling CLOSE_WAIT state on sockets accepted by the daemon's axum listener can outlive the daemon. Setting SO_LINGER 0 on every accepted socket forces an immediate RST on close instead of the FIN / CLOSE_WAIT / TIME_WAIT dance. Requires hooking into the axum accept loop or implementing a custom Listener/IncomingStream wrapper. Regression test exists at crates/fbuild-daemon/tests/port_recovery.rs (run with --ignored).

• SetConsoleCtrlHandler for Windows CTRL_CLOSE / LOGOFF / SHUTDOWN events (was Outstanding work: ledger removal, send_op errors, async API, B5a hardening, espflash native, sector-selective flashing #18 item 4a) — merged in PR feat(daemon): Windows console ctrl handler for graceful shutdown (#18) #61

Why one issue

All three mechanisms target the same outcome: a daemon that terminates cleanly under every termination path (graceful, Ctrl+C, window close, logoff, shutdown, hard-kill) without leaking child processes, sockets, or file handles. Keeping them in one tracker makes it clear which hardening surfaces remain.

Context

The sidecar concern that zccache may also participate in the Windows orphan chain — see original scope note below — still warrants a linked issue in the zccache repo once process containment lands here.

Original scope (preserved for reference)

fbuild should move daemon and long-lived subprocess management over to running-process so child/grandchild trees are explicitly contained and torn down on parent exit.

We are seeing orphaned shell / console-host processes in Windows (bash.exe, conhost.exe, OpenConsole.exe) after higher-level jobs disappear. The current failure mode looks like a process-management gap, not just a one-off hung command.

Why running-process: Recent running-process work already added the containment primitives needed for this — ContainedProcessGroup / Containment in commits 4fccf1b and 868faa1. Windows uses Job Objects with kill-on-close semantics; Linux/macOS use process groups, with extra Linux parent-death handling. Tests explicitly cover killing contained children and grandchildren.

Requested change: Use running-process for all daemon / worker / background process spawning in fbuild, especially on Windows. Wrap daemon lifetime in ContainedProcessGroup. Ensure every subprocess that should die with fbuild is spawned as contained, not detached. Reserve detached mode only for intentionally persistent daemons.