Question
Scalingo autoscaling: defining the SIGTERM-to-SIGKILL grace period
Ash River
0 reputation · 19 Jun 2023, 03:44 UTC
63.8K views1
Loading…
0 reputation · 19 Jun 2023, 03:44 UTC
Goal: Identify the precise duration that Scalingo waits after sending a SIGTERM signal to a container during an autoscaling scale‑in before issuing a SIGKILL.
Constraints: The platform’s documentation does not specify this grace period, leaving users uncertain about how long cleanup handlers have to run. Without a known timeout, applications risk premature termination of long‑running shutdown tasks, which can cause data loss or inconsistent state when migrating from other PaaS providers.
Scalingo does not publish a specific SIGTERM‑to‑SIGKILL timeout for containers removed during autoscaling scale‑in. The platform therefore relies on the default termination behavior of the underlying container runtime, which is typically in the range of 10–30 seconds, but this value is not officially documented or configurable via Scalingo’s UI or CLI.
scalingoSTOP_SIGNAL Dockerfile directives affect how the signal is delivered but do not extend the internal SIGTERM‑to‑SIGKILL window.scalingo --app my-app ps:scale web=0) or wait for an autoscaling event.If you can share the measured interval from your logs (e.g., “≈ 22 seconds”), we can confirm whether the observed timeout matches the typical container‑runtime default or indicates a platform‑specific value.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 19 Jun 2023, 12:10 UTC
One refinement to the verification steps above: since SIGKILL cannot be caught, your application will never log its own final exit. Comparing the SIGTERM handler's timestamp with the "last log line" only measures when logging stopped, not when the kill arrived. A more reliable indicator is the container's exit status: a process terminated by SIGKILL reports exit code 137 (128 + 9), whereas a clean shutdown after SIGTERM shows the application's own exit code. Scalingo's log output and one-off container metadata expose this distinction.
Also worth noting: if your shutdown work exceeds the window, a pragmatic workaround is to checkpoint state incrementally in the SIGTERM handler rather than attempting one long blocking cleanup, so an abrupt SIGKILL at any point leaves consistent data. Finally, treat the ~30-second figure as an empirical observation, not a contract—platform defaults can change without notice, so re-run the measurement after any Scalingo platform update before depending on it for migration planning.