Self-hosted runners can keep serving attached sessions on the first shutdown signal instead of draining.
What's wrong with this entry?
New flag --defer-shutdown-max-min <m> makes the first SIGTERM stop the runner accepting new work while it keeps serving attached sessions, rather than starting the drain budget straight away. It writes SELF_HOSTED_RUNNER_DEFER_SHUTDOWN_MAX_MS; 0 disables it and is the default, so operators who do not pass the flag see no change.
- After M minutes everything still attached is released through the park path; a further grace period later it drains as a last resort. It exits 0 as soon as no session is held.
- A second signal drains immediately; a third force-exits.
- Help text warns that the supervisor's stop timeout must exceed M minutes plus the grace plus the shutdown budget, and the troubleshooting table gained a row for the new exit line.
- New telemetry points
self_hosted_defer_shutdownandself_hosted_defer_ceiling; poll-failure backoff now distinguishes timeout and transport errors from 5xx responses.
claude self-hosted-runner --defer-shutdown-max-min 30--defer-shutdown-max-min, --defer-shutdown-max-min <m>
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Self-hosted runners report when warm-up finished
Both mention self hosted runner
-
v2.1.236
Self-hosted runner releases a session only after its work finishes
Both mention self hosted runner
-
v2.1.236
Runner waits for sessions to be released before shutting down
Both mention self hosted runner