CHEATSHEETSTOOLSBOOKSHELFABOUT中文

POSIX Signals - SIGKILL

SIGKILL (Kill, signal number 9) is the ultimate, non-negotiable termination signal defined by POSIX standards.

Unlike standard signals like SIGTERM or SIGINT, POSIX guarantees that SIGKILL cannot be caught, blocked, or ignored. When SIGKILL is issued, the operating system kernel bypasses user space entirely, immediately destroying the process without executing any further application code.

Kernel Mechanics: What Happens During kill -9

Because the application never sees or handles SIGKILL, the kernel performs the destruction unilaterally:

  1. Immediate Execution Freeze: The thread is immediately removed from the CPU run queue (scheduler). No cleanup code, destructor, atexit() callback, or finally block runs.
  2. Resource Reclamation:
    • The kernel tears down the process's page tables and reclaims all physical RAM allocations.
    • All open file descriptors (sockets, pipes, files) are closed, sending TCP FIN or RST packets to connected network peers.
    • Any held advisory POSIX file locks (fcntl) are automatically released.
    • Shared memory handles are detached (though the underlying named memory segments persist until unlinked).
  3. Transition to Zombie: The kernel writes the child's termination status (WIFSIGNALED with signal 9) and converts the process into a Zombie (<defunct>), delivering a SIGCHLD signal to the parent process.

The Two Scenarios Where kill -9 Fails

Many systems administrators are shocked when a process refuses to die even after running kill -9 <PID>. There are only two reasons this occurs in Linux:

1. The Process is in D State (Uninterruptible Sleep)

In Linux, a process waiting on deep kernel hardware I/O (such as waiting for a physical hard drive to respond, or blocked on an unresponsive NFS network share) enters the TASK_UNINTERRUPTIBLE (D state).

  • While in D state, the CPU halts the process and instructs the scheduler not to deliver any signals—including SIGKILL—until the hardware driver returns.
  • If an NFS storage server freezes or a SATA drive hangs, the process will remain stuck in D state indefinitely.
  • Solution: SIGKILL remains pending in the kernel. The moment the disk or NFS responds, the process terminates immediately. If the hardware is permanently hung, only a system reboot will clear it.

2. The Process is Already a Zombie (Z State)

A zombie process (<defunct>) is already dead. It has no memory, no open files, and no CPU thread context.

Because it does not exist as an executable entity, you cannot "kill" it. A zombie exists solely as a 64-byte row in the kernel's process table waiting for its parent to read its exit status with waitpid().

The Linux OOM Killer (Out-of-Memory Killer)

When a Linux system runs completely out of available RAM and swap space, the kernel invokes the OOM Killer to prevent a total operating system freeze.

  1. The kernel calculates an oom_score for every running process based on physical memory usage, process lifetime, and the configured /proc/[pid]/oom_score_adj.
  2. The kernel chooses the process with the highest score and delivers a SIGKILL to it directly inside the kernel memory allocator.
  3. The event is logged to dmesg: Out of memory: Killed process 1234 (java) total-vm:8234056kB, anon-rss:4123012kB.

When Should You Use SIGKILL?

SIGKILL should strictly be used as a last resort:

Approach Command Use Case
First Attempt kill <PID> (SIGTERM) Allows process to flush buffers, commit database records, and finish in-flight network requests.
Second Attempt kill -2 <PID> (SIGINT) Interactive interruption (equivalent to pressing Ctrl+C).
Last Resort kill -9 <PID> (SIGKILL) Use only after a grace period (e.g. 10–30 seconds) if the process is completely hung, unresponsive, or spinning.

Frequently Asked Questions (FAQ)

Can a process block or catch SIGKILL?

No. POSIX guarantees that SIGKILL (along with SIGSTOP) cannot be caught by any signal handler, blocked by sigprocmask(), or ignored by SIG_IGN. The signal is handled directly and unconditionally by the kernel's process termination code.

Why does kill -9 sometimes not kill a process in Linux?

kill -9 fails to kill a process only if the process is in Uninterruptible Sleep (D state) waiting for hung disk or network I/O, or if the process is already a dead Zombie (Z state). A process in D state holds the signal as pending until the kernel driver returns from the hardware operation.

Does SIGKILL cause data corruption?

Yes, SIGKILL can cause data corruption if the process was in the middle of writing to a database or file without atomic write guarantees. Because no user-space cleanup or buffer flushing code executes, partially written files or uncommitted in-memory states are lost.

Related Topics