wtclaude
96af2afa68
All checks were successful
PR Checks / rust-gates (pull_request) Successful in 2m22s
`sc.exe start RunicGatewayLink` failed with 1053 on every Windows install:
"a timeout was reached (30000 milliseconds) while waiting for the service to
connect", with SERVICE_EXIT_CODE 0. Nothing had crashed. The sidecar was a
plain console program, and the Windows service control manager only supervises
a process that calls StartServiceCtrlDispatcher and identifies itself within
~30 seconds.
The installer's design assumed symmetry with systemd, which supervises any
foreground process. Windows has no equivalent: it is a service-aware binary or
a shim, and a shim was already rejected as a third binary to keep current.
Split the entry point so the platform only owns starting and stopping:
systemd --> main --> unix::run ---------------+
+--> app::run
SCM ------> main --> windows::run --> ServiceMain
\-> console fallback
- app.rs is the whole sidecar, unchanged and shared. No #[cfg] on the data path.
- windows.rs speaks the SCM handshake. The dispatcher is tried first and failing
is expected: ERROR_FAILED_SERVICE_CONTROLLER_CONNECT (1063) means "not started
by the SCM" and falls through to a normal foreground run, so one binary does
both with no --service flag to forget.
- Running is reported only once the shard port is bound and the store is open, so
a bad config fails the start instead of flapping Running -> Stopped, and a
failed run leaves a nonzero SERVICE_EXIT_CODE instead of the misleading 0.
- A service has no stdout, so service mode logs to uo-link-sidecar.log.<date>
beside its config, rolled daily, seven kept.
- unix.rs additionally handles SIGTERM, which is what systemctl stop sends and
which previously took the default disposition mid-write.
The Windows crates are declared under [target.'cfg(windows)'.dependencies].
Verified: a Linux build in rust:1-slim-bookworm succeeds and resolves neither
windows-service nor tracing-appender.
Co-Authored-By: Claude <noreply@anthropic.com>
29 lines
1.1 KiB
TOML
29 lines
1.1 KiB
TOML
[package]
|
|
name = "uo-link-sidecar"
|
|
version = "0.1.0"
|
|
edition = "2021"
|
|
description = "Rust sidecar for the ServUO uo-link bridge: terminates the loopback link to the shard and exposes WebSocket + REST to the website."
|
|
|
|
[dependencies]
|
|
tokio = { version = "1", features = ["rt-multi-thread", "macros", "net", "io-util", "sync", "time", "signal"] }
|
|
serde = { version = "1", features = ["derive"] }
|
|
serde_json = "1"
|
|
tracing = "0.1"
|
|
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
|
|
anyhow = "1"
|
|
axum = { version = "0.7", features = ["ws"] }
|
|
sqlx = { version = "0.8", features = ["runtime-tokio", "sqlite"] }
|
|
toml = "0.8"
|
|
getrandom = "0.2"
|
|
chrono = { version = "0.4", default-features = false, features = ["std", "clock"] }
|
|
|
|
# Speaking the Windows Service Control Manager's startup handshake, and logging somewhere other
|
|
# than the stdout a service does not have. Declared per target so Cargo neither resolves nor builds
|
|
# either crate for Linux — the Linux binary is byte-for-byte unaffected by Windows service support.
|
|
[target.'cfg(windows)'.dependencies]
|
|
windows-service = "0.8"
|
|
tracing-appender = "0.2"
|
|
|
|
[profile.release]
|
|
opt-level = 2
|