Module service 

Platform service registration and lifecycle management (server-windows-service).

Only the imperative Windows Service Control Manager (SCM) glue is #[cfg(target_os = "windows")] – it is invisible to the Linux/macOS coverage runs, so it is kept as thin as possible. Everything that can be plain, platform-neutral logic (the service’s identity/definition, how CLI flags become launch arguments, the reporting order of the SCM lifecycle, and how a “not launched by the SCM” failure is recognized) lives at the top of this file, is exercised by the tests below on every platform (including CI’s windows-latest job, which compiles and runs the #[cfg(windows)] section too – see .github/workflows/checks.yml), and is only mapped onto the real windows_service types inside the Windows-only section. Mirrors opcda-bridge-gateway’s own service.rs (same crate, same design), generalized for a binary that – unlike that Windows-only gateway – genuinely runs cross-platform.

Linux and macOS have no equivalent self-registration API: the idiomatic path there is a static unit/plist file an administrator (or a future .deb/.rpm/Homebrew package) installs with the OS’s own tooling, not something this binary does to itself at runtime – see packaging/systemd/bhtune-server.service and packaging/launchd/com.bytehound-labs.bhtune-server.plist. So on those platforms, this module’s public functions are still real (not #[cfg(windows)]-gated away, so bhtune-server install on Linux fails with a helpful message rather than clap rejecting an unrecognized subcommand outright), but they only explain that and point at the relevant packaging file instead of touching anything.

Structs

ServiceDefinition

Plain, platform-neutral description of how the server should be registered with the SCM. Built and tested independent of the Windows-only windows_service::service::ServiceInfo it is later mapped onto one field at a time, so this construction logic runs – and is covered – on every platform.

Enums

ServiceLifecycle

The SCM status lifecycle bhtune-server reports while running as a Windows service, kept as a plain enum (rather than directly using windows_service::service::ServiceState, which only exists on Windows) purely so the expected reporting order is itself unit-testable on every platform. The Windows-only reporting code maps each variant onto the real SCM API one-to-one.

Constants

SERVICE_DESCRIPTION

Shown as the service’s description in services.msc.

SERVICE_DISPLAY_NAME

Human-readable name shown in services.msc.

SERVICE_NAME

Service name registered with the SCM (used for sc query, event log sourcing, etc. – must contain no spaces).

Functions

build_service_definition

Build the platform-neutral service definition used by install, pairing the current executable’s path with whichever CLI flags should carry over into the service’s own launch.

install

is_scm_launch_error_code

True when code is the raw OS error that means “this process wasn’t started by the SCM” – i.e. main should fall back to running the server directly in the foreground rather than treating this as a real failure. Kept as a plain function over the numeric code (rather than matching directly on windows_service::Error, which only exists on Windows) so this small but important piece of “which failure means fall back to console mode” logic is still covered by the cross-platform test run.

service_launch_arguments

Re-serialize whichever CLI flags were given to install into the argument list the SCM should launch the executable with. The SCM always starts a service’s executable bare (no interactive shell, no inherited environment beyond the system default – notably including a different %APPDATA% than whichever user ran install interactively, since services typically run under their own account), so an explicit --config an operator wants applied every time the service starts must be baked into the registration itself rather than relying on how the executable happened to be invoked once at install time – see crate::cli’s module doc comment.

start

status

stop

uninstall