Difference Between SIGTERM and SIGKILL in Linux
In the Linux operating system, terminating an application can be achieved through various signals, the two most common being SIGTERM and SIGKILL. While both signals cause a process to stop running, they fundamentally differ in how they achieve it. SIGTERM acts as a polite request that allows an application to run cleanup routines and terminate gracefully, whereas SIGKILL is an unconditional command directed at the kernel that forces an immediate stop, bypassing the process entirely and risking data loss or state corruption.
What Is SIGTERM (Signal 15)?
SIGTERM (Signal Termination) is the standard signal sent to a process
when using the default kill <PID> command. It serves
as a gentle request to shut down.
Because SIGTERM is delivered directly to the application, the process has the ability to intercept, handle, or ignore it. Well-designed applications register a signal handler specifically for SIGTERM to initiate a graceful shutdown sequence. During a graceful shutdown, a process can:
- Close open file descriptors and network sockets cleanly.
- Commit pending database transactions and flush memory buffers to disk.
- Remove temporary lock files and PID files.
- Notify connected clients or child processes of the impending shutdown.
By providing the process with an opportunity to tidy up its environment, SIGTERM prevents resource leakage and data corruption.
What Is SIGKILL (Signal 9)?
SIGKILL (Signal Kill), executed via commands such as
kill -9 <PID>, is an absolute termination order.
Unlike SIGTERM, SIGKILL is not sent to the application process; instead, it is handled directly by the Linux kernel. Because of this, the target process cannot catch, block, or ignore the signal. The kernel immediately removes the process from the process table and reclaims its allocated memory and system resources.
The primary drawback of SIGKILL is that the application is given zero execution time to perform cleanups. Any unsaved data in memory is lost, database states can be left partially written or corrupted, and lock files on the filesystem may remain behind, preventing the service from restarting properly.
Key Differences at a Glance
- Interception: SIGTERM can be caught, handled, or blocked by the program's code. SIGKILL cannot be intercepted or ignored under any circumstance.
- Cleanup Capability: SIGTERM allows developers to write exit routines that properly save state. SIGKILL terminates the process abruptly without running any exit routines.
- Handler: SIGTERM is handled by the process itself. SIGKILL is acted upon entirely by the Linux kernel.
- Risk Factor: SIGTERM preserves data integrity. SIGKILL introduces a significant risk of file corruption and broken state.
Best Practices for Process Termination
In production environments, modern init systems like
systemd and container runtimes like Docker follow a
staggered approach to process termination. The established best practice
is to always issue a SIGTERM first to allow the application a designated
grace period (typically 10 to 30 seconds) to wrap up operations. SIGKILL
should only ever be used as a last resort when an application has
completely frozen, entered an unrecoverable loop, or failed to stop
within its designated grace period.