Module run 

The actual bhtune-server bootstrap-and-serve sequence, split out of main.rs so it can be driven either 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 through the shared runtime resolver), 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. Unix signal handlers are installed when this function is called, before the server starts accepting connections, so an immediate shutdown signal cannot hit the default process handler. 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. Installing a handler returns an error instead of panicking, so a failed install cannot take down a process that may already be serving requests.