v2.173.1

API shutdown is now bounded — a stuck deploy no longer waits the full systemd kill window

A real deploy on this box measured the API taking the full ~90s systemd
default TimeoutStopSec (unset in our unit) to stop on SIGTERM, because
axum::serve(...).with_graceful_shutdown(...) waits for every in-flight
connection to close on its own — an open SSE stream or WebSocket terminal
session blocks that indefinitely. Fixed by arming a hard watchdog inside
shutdown_signal() once the signal has actually fired: it sleeps 20s, then
forces the process to exit if the drain (plus the background-service
shutdown and DB-pool close that follow it) hasn't finished on its own. A
first fix attempt — wrapping the whole axum::serve(...) .with_graceful_shutdown(...) future in a tokio::time::timeout — was caught
in review before shipping: that future runs for the server's entire uptime,
so timing out the whole thing would have force-exited the process ~20s after
every single boot, shutdown or not. The corrected version only starts its
clock once the shutdown signal has resolved. Verified live on a throwaway
VPS under the same unmodified systemd unit as production: SIGTERM with a
held-open connection went from 90s to 20s exactly (confirmed via journal
timestamps), while a normal shutdown with no open connections stayed a fast
~2s, and the server was independently confirmed to stay up and healthy well
past the 20s bound with no shutdown signal sent at all.

---

Install: curl -sL dockpanel.dev/install.sh | bash

Every release is installed on a throwaway VPS and driven as a user before
it ships. What that means, and what it has found, is written up at
https://docs.dockpanel.dev/testing.html.

Binaries are static musl builds signed with Sigstore; checksums.txt
and the .sig/.pem pairs are attached below.

Full changelog: v2.173.0...v2.173.1