Module lifecycle 

Daemon lifecycle: PID file, launch (Unix double-fork+exec), stop.

On Unix the launch sequence is: parse CLI, authenticate in the foreground (so Steam Guard works), save the refresh token via the existing save_token path, fork once to escape the controlling terminal, setsid, fork again, then exec the same binary with a --daemon-resume flag. The resumed child rebuilds a fresh tokio runtime, re-authenticates using the saved token (fast, no prompts), binds the socket, and enters the accept loop. The original parent waits on a pipe for the resumed child to report its PID, prints the info block, and exits 0.

Functions

detach_and_exec_resume

Spawn the daemon child detached from this process and probe the socket until it binds.

launch_daemon_authenticate

Phase 1 of daemon start: preflight + foreground authentication.

load_recent_history

Load persisted recent-job history, if any, into the given state’s ring. Silent on failure – a missing or corrupt file just means we start with an empty history.

log_path

pid_file_path

read_pid_file

recent_history_path

Path to the JSON file where the daemon persists its recent ring on shutdown and reloads on startup. Co-located with the PID and log.

remove_pid_file

render_daemon_info

Render the daemon info block to stdout. Does NOT contact the daemon. Useful for diagnosing a wedged daemon.

save_recent_history

Snapshot the recent ring to disk. Best-effort: any I/O failure is logged but does not block shutdown.

serve_resumed

The actual long-lived daemon process, post-exec. Builds a fresh tokio runtime above this; this just runs the accept loop.

write_pid_file