Module run 

The actual bhtune-server bootstrap-and-serve sequence, split out of main.rs so it can be driven two different ways (server-windows-service): directly, from an interactive console session or a systemd/launchd-managed foreground process, or from inside the Windows Service Control Manager’s own callback thread (crate::service’s #[cfg(windows)] glue), which needs its own shutdown trigger (an SCM Stop/Shutdown control event) instead of Ctrl+C/SIGTERM.

Split into two phases rather than one long function, so a caller that needs to know the exact moment the server is actually ready to accept connections (the Windows service path reports SERVICE_RUNNING to the SCM at that point, not a moment earlier) can await build_server and only then move on – see BoundServer.

Structs

BoundServer

A bhtune-server that has finished every startup step through binding its listening socket – config/log/db resolution, migrations, template/retention seeding – and is ready to actually start accepting connections, but has not yet been handed to serve. Returned as one value (rather than serve doing all of this itself) so a caller can observe “fully bound and ready” as a distinct moment from “now serving until told to stop” – see this module’s doc comment.

Functions

build_server

Runs every step of bhtune-server’s startup through binding its listening socket: resolve config (an explicit config_path if given, otherwise the platform’s auto-discovered path – mirroring bhtune-cli calling load_config(None) whenever --config itself wasn’t passed), init logging, open/migrate/seed the database, spawn the periodic retention sweeper, and bind the configured address.

serve

Serves server until shutdown resolves, then drains in-flight HTTP connections and cancels/waits for any still-active tune run before returning – the interactive path’s main.rs awaits shutdown_signal; the Windows service path (crate::service::windows_impl) awaits its own SCM-driven signal instead.

shutdown_signal

Waits for Ctrl+C (SIGINT), or on Unix, SIGTERM – so a service manager’s ordinary “stop” request (systemctl stop, launchctl stop) drains in-flight requests the same way an interactive Ctrl+C does, rather than dropping connections mid-response. The Windows Service Control Manager’s own Stop/Shutdown control codes don’t arrive as either of these signals – see crate::service::windows_impl::run_service for the SCM-specific equivalent used instead when running as a Windows service.