Skip to content

feat(daemon): Windows console ctrl handler for graceful shutdown (#18)#61

Merged
zackees merged 1 commit intomainfrom
fix/issue-18-console-ctrl-handler
Apr 17, 2026
Merged

feat(daemon): Windows console ctrl handler for graceful shutdown (#18)#61
zackees merged 1 commit intomainfrom
fix/issue-18-console-ctrl-handler

Conversation

@zackees
Copy link
Copy Markdown
Member

@zackees zackees commented Apr 17, 2026

Summary

Registers a Windows SetConsoleCtrlHandler so the daemon catches CTRL_CLOSE_EVENT (terminal window closed), CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT and funnels them into the same shutdown_tx channel the HTTP shutdown endpoint and Ctrl+C paths already use.

Without this hook, those three events terminate the daemon immediately — skipping graceful shutdown and leaving stale PID / port files behind. tokio::signal::ctrl_c() only covers CTRL_C_EVENT / CTRL_BREAK_EVENT on Windows, so it doesn't help here.

Context

Addresses the SetConsoleCtrlHandler half of the B5a hardening leftovers in #18. The companion SO_LINGER 0 piece stays deferred because it needs per-accepted-socket access that axum doesn't currently expose.

Implementation notes

  • Module is #[cfg(windows)], call site is #[cfg(windows)] — no behavior change on Unix builds.
  • OnceLock<watch::Sender<bool>> holds the shutdown sender because SetConsoleCtrlHandler's callback has a fixed C-ABI signature with no user-data pointer.
  • Handler blocks for ~3.5s after sending the shutdown signal so the main graceful-shutdown path can complete before the ~5s CTRL_CLOSE_EVENT deadline forces termination. If main exits sooner, the sleep is cut short.
  • Returns TRUE only for the three target events; CTRL_C and CTRL_BREAK fall through to the existing tokio handler.

Test plan

  • uv run cargo clippy --workspace --all-targets -- -D warnings clean
  • uv run cargo test -p fbuild-daemon --lib — 88 passed
  • CI green on Linux / macOS / Windows (the cfg-gated module must not break non-Windows builds)

🤖 Generated with Claude Code

…down (#18)

On Windows, tokio::signal::ctrl_c() covers CTRL_C_EVENT and
CTRL_BREAK_EVENT but NOT CTRL_CLOSE_EVENT (terminal window closed),
CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT. Without an explicit handler,
those events terminate the daemon immediately, skipping graceful
shutdown and leaving stale PID / port files behind.

Register a SetConsoleCtrlHandler routine that funnels those three
events into the same shutdown_tx channel the HTTP shutdown endpoint
and Ctrl+C paths use. The handler blocks for ~3.5s to give the main
graceful-shutdown path room to run before Windows force-kills at the
~5s CTRL_CLOSE deadline; the sleep is cut short if `main` exits first.

Addresses the "SetConsoleCtrlHandler" half of the B5a hardening
leftovers tracked in #18.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 17, 2026

Warning

Rate limit exceeded

@zackees has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 29 minutes and 52 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 29 minutes and 52 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 36445135-c793-452f-a8c5-6ae2956d10e8

📥 Commits

Reviewing files that changed from the base of the PR and between 22fff83 and 5ec0393.

📒 Files selected for processing (1)
  • crates/fbuild-daemon/src/main.rs
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/issue-18-console-ctrl-handler

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@zackees zackees merged commit f6c48f1 into main Apr 17, 2026
75 of 76 checks passed
@zackees zackees deleted the fix/issue-18-console-ctrl-handler branch April 17, 2026 16:44
zackees added a commit that referenced this pull request Apr 18, 2026
…leaks (partial #32)

Set SO_LINGER=0 on the daemon's listening socket before `listen(2)` so
that accepted client sockets inherit a zero linger and force an
immediate RST on close instead of going through FIN / CLOSE_WAIT /
TIME_WAIT. After a hard-kill of the daemon, this prevents the kernel
from leaking dangling CLOSE_WAIT state on client sockets that outlives
the daemon itself and would otherwise block a fresh instance from
re-binding the port.

SO_LINGER is inherited from the listener by accept(2) on Linux, macOS,
and Windows (AFD.sys), so setting it once on the listener covers every
accepted connection without needing to hook axum 0.7's internal
accept loop (axum 0.7 hands accept off to hyper-util inside `serve`
with no per-connection extension point).

Verified with the pre-existing regression test at
crates/fbuild-daemon/tests/port_recovery.rs (run with `--ignored`),
which hard-kills a daemon holding an open TCP connection and asserts
a second daemon can re-bind the port cleanly.

Remaining on #32: process containment via the `running-process` crate
(Windows Job Object + POSIX process group parent-death). The
SetConsoleCtrlHandler piece landed earlier in PR #61.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zackees added a commit that referenced this pull request Apr 18, 2026
…leaks (partial #32)

Set SO_LINGER=0 on the daemon's listening socket before `listen(2)` so
that accepted client sockets inherit a zero linger and force an
immediate RST on close instead of going through FIN / CLOSE_WAIT /
TIME_WAIT. After a hard-kill of the daemon, this prevents the kernel
from leaking dangling CLOSE_WAIT state on client sockets that outlives
the daemon itself and would otherwise block a fresh instance from
re-binding the port.

SO_LINGER is inherited from the listener by accept(2) on Linux, macOS,
and Windows (AFD.sys), so setting it once on the listener covers every
accepted connection without needing to hook axum 0.7's internal
accept loop (axum 0.7 hands accept off to hyper-util inside `serve`
with no per-connection extension point).

Verified with the pre-existing regression test at
crates/fbuild-daemon/tests/port_recovery.rs (run with `--ignored`),
which hard-kills a daemon holding an open TCP connection and asserts
a second daemon can re-bind the port cleanly.

Remaining on #32: process containment via the `running-process` crate
(Windows Job Object + POSIX process group parent-death). The
SetConsoleCtrlHandler piece landed earlier in PR #61.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant