fix(service): start the Windows service after granting it its config (D157) #31

Merged
whitlocktech merged 1 commits from fix/windows-start-after-grant into edge 2026-09-26 09:00:31 +00:00
Member

Found on the phase 18 walk (§34.3 step 4, one Rust instance under the SCM). It also affects the released ServUO installer, since the code is shared; the org lead chose to fix both games here (D157).

The defect

install on Windows left the service STOPPED:

service          RunicGatewayRust-main   STOPPED, automatic start

sc query showed WIN32_EXIT_CODE 1066 (a service-specific error), and the sidecar's own log said why:

INFO  rust-link sidecar starting
ERROR sidecar failed error=Access is denied. (os error 5)

sc start ran inside registration, before grant_service_access let the new virtual account read sidecar.toml. protect_config locks that file to SYSTEM and Administrators because it holds the token, so the first start couldn't read its own config. The SCM's restart-on-failure policy doesn't fire for a clean exit with an error code, so the service stayed stopped until someone started it by hand; by then the grant existed and the start worked. main (v0.2.0) has the same order in install.rs, so a first-time ServUO install on Windows does this too.

The fix

  • register_windows_named registers, reconfigures and sets the restart policy. It no longer starts the service.
  • A new service::start_registered runs after grant_service_access (in both install.rs and rustgame/install.rs), keeps the 1053/1069 diagnoses, and refreshes the reported state.
  • It's a no-op on Linux, where the service user exists before the config and registration starts the unit itself.

Proof

  • Windows, elevated, from this branch: install → START_PENDING, automatic start → running; /health answered on the first probe; stop in 22 ms; restart; doctor clean (⚠ only for the server not running); uninstall removed everything it listed.

  • fmt, and clippy -D warnings plus the tests on both Windows (163) and Linux (166).

  • The ServUO path was not walked on Windows; it goes through the identical registration and start code.

  • AI-assisted: Claude Code (Claude Opus 5.5)

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Found on the phase 18 walk (§34.3 step 4, one Rust instance under the SCM). **It also affects the released ServUO installer**, since the code is shared; the org lead chose to fix both games here (**D157**). ## The defect `install` on Windows left the service **STOPPED**: ``` service RunicGatewayRust-main STOPPED, automatic start ``` `sc query` showed `WIN32_EXIT_CODE 1066` (a service-specific error), and the sidecar's own log said why: ``` INFO rust-link sidecar starting ERROR sidecar failed error=Access is denied. (os error 5) ``` `sc start` ran **inside** registration, before `grant_service_access` let the new virtual account read `sidecar.toml`. `protect_config` locks that file to SYSTEM and Administrators because it holds the token, so the first start couldn't read its own config. The SCM's restart-on-failure policy doesn't fire for a clean exit with an error code, so the service stayed stopped until someone started it by hand; by then the grant existed and the start worked. `main` (v0.2.0) has the same order in `install.rs`, so a first-time **ServUO** install on Windows does this too. ## The fix - `register_windows_named` registers, reconfigures and sets the restart policy. It no longer starts the service. - A new `service::start_registered` runs after `grant_service_access` (in both `install.rs` and `rustgame/install.rs`), keeps the 1053/1069 diagnoses, and refreshes the reported state. - It's a no-op on Linux, where the service user exists before the config and registration starts the unit itself. ## Proof - Windows, elevated, from this branch: install → `START_PENDING, automatic start` → running; `/health` answered on the first probe; stop in 22 ms; restart; `doctor` clean (⚠ only for the server not running); uninstall removed everything it listed. - `fmt`, and `clippy -D warnings` plus the tests on **both** Windows (163) and Linux (166). - The ServUO path was **not** walked on Windows; it goes through the identical registration and start code. - [x] AI-assisted: Claude Code (Claude Opus 5.5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
wtclaude added 1 commit 2026-09-26 08:55:14 +00:00
fix(service): start the Windows service after granting it its config (D157)
All checks were successful
PR Checks / rust-gates (pull_request) Successful in 1m8s
70eb073826
`sc start` ran inside registration, before `grant_service_access` let the
new virtual account read `sidecar.toml` — which `protect_config` had
locked to SYSTEM and Administrators. The first start died on "Access is
denied (os error 5)" and the service sat STOPPED: the SCM's
restart-on-failure policy never fires for a clean exit with an error
code. A later manual start worked, because by then the grant existed.

Found on the phase 18 walk (step 4, one Rust instance under the SCM),
from the sidecar's own log. The code is shared, so the released ServUO
installer has the same first-start failure; the org lead chose to fix
both here (D157).

Registration no longer starts the service; a new `start_registered`
runs after the grant and refreshes the reported state. A no-op on Linux,
where the service user exists before the config and registration starts
the unit itself.

Walked (Windows, elevated): install -> START_PENDING/running, /health on
the first probe, clean stop and restart, doctor clean, uninstall clean.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
whitlocktech merged commit 0f19fd6413 into edge 2026-09-26 09:00:31 +00:00
whitlocktech deleted branch fix/windows-start-after-grant 2026-09-26 09:00:32 +00:00
Sign in to join this conversation.
No description provided.