Signals — how a process gets interrupted, paused, or killed

A signal is the kernel's mechanism for asynchronously notifying a process that something happened — press Ctrl+C in a terminal, and the kernel delivers a specific signal to the running program; run kill <pid>, and the kernel delivers a different one. Crucially, a signal is a notification, not a forced action performed on the process from outside — what happens next depends on how (or whether) the process has chosen to handle that particular signal.

Reaching for kill -9 when a process seems stuck skips past the graceful shutdown path entirely — which is sometimes genuinely necessary (a truly hung process that isn't responding to SIGTERM at all), but always at the cost of whatever cleanup that process would otherwise have done. A database process killed with -9 mid-write, for instance, may leave data in an inconsistent state that a graceful SIGTERM shutdown would have avoided — this is exactly why production tooling (container orchestrators, systemd) sends SIGTERM first and only escalates to SIGKILL after giving the process a real window of time to exit cleanly on its own.

Registering a handler like this is what lets a real service — a web server, a background worker — finish its current request and shut down cleanly instead of being cut off mid-task whenever it's asked to stop.

Whether a deployment or a container restart is "clean" almost always comes down to whether the running process actually handles SIGTERM properly before the orchestrator's patience runs out and escalates to SIGKILL. A service that ignores SIGTERM (or takes too long to react to it) is a concrete, common cause of dropped requests and corrupted in-progress work during otherwise routine deploys.