Overview
SIGTERM and SIGKILL are both Unix signals used to stop a running process, but they differ in whether the process gets a chance to clean up after itself. SIGTERM asks a process to terminate and lets it run its own shutdown logic, while SIGKILL is an unconditional kernel-level termination that the process cannot intercept or delay. The distinction matters for avoiding data corruption, leaked resources, and orphaned locks during shutdown.
Comparison Diagram
Comparison Table
| Aspect | SIGTERM | SIGKILL |
|---|---|---|
| Signal number | 15 | 9 |
| Triggered by | kill, docker stop, systemctl stop, Kubernetes preStop hook | kill -9, orchestrator escalation after grace period, OOM killer |
| Can be caught or blocked | Yes, process can install a handler, ignore it, or delay it | No, delivered directly by the kernel and cannot be caught, blocked, or ignored |
| Cleanup opportunity | Handler can flush buffers, close sockets, release locks, save state | None, process’s own code never runs before removal |
| Termination timing | Not guaranteed, depends on handler duration or can hang indefinitely | Near-immediate, enforced by the kernel except for processes stuck in uninterruptible D state |
| Resulting exit status | Depends on handler logic, default 143 (128+15) if unhandled | Always 137 (128+9), no application-level exit path |
| Typical role | First step in a graceful shutdown sequence | Last-resort escalation when SIGTERM is ignored or the process is hung |
Key Differences
- SIGTERM is catchable, letting a process run its own shutdown handler before exiting.
- SIGKILL bypasses userspace entirely and is enforced directly by the kernel, so it cannot be intercepted.
- Only SIGTERM gives a process the chance to perform cleanup like flushing writes or releasing locks.
- Orchestrators like Docker and Kubernetes send SIGTERM first, then escalate to SIGKILL after a grace period.
- Processes stuck in uninterruptible D state I/O wait can delay even SIGKILL until the I/O completes.
When to Use Each
SIGTERM
- Default Shutdown Signal: Tools like
docker stop,systemctl stop, and Kubernetes preStop hooks send SIGTERM first, giving the process a chance to run its own shutdown handler. - Flushing State Before Exit: When a process needs to flush buffers, close sockets, or release locks cleanly, only SIGTERM’s catchable handler provides that window.
- Predictable Exit Codes for Monitoring: Since an unhandled SIGTERM exits with code 143, orchestration and monitoring tooling can distinguish a normal graceful stop from other failure modes.
SIGKILL
- Unresponsive or Hung Processes: When a process ignores SIGTERM or hangs indefinitely, SIGKILL’s kernel-enforced termination guarantees it actually stops.
- OOM Killer Reclaiming Memory: The kernel’s out-of-memory killer uses SIGKILL specifically because it cannot be intercepted or delayed by the target process.
- Final Escalation After a Grace Period: Orchestrators like Kubernetes send SIGKILL only after a configured grace period expires post-SIGTERM, accepting the risk of orphaned resources to force termination.