Recommended Free Tools
SIGKILL can’t be caught, blocked or ignored by the process that receives it. Yet a process stuck in an uninterruptible wait (state D in ps and top) can stay in the process list after kill -9. The signal isn’t being refused. The task is inside kernel code that hasn’t reached a point where it can act on it, or it has already finished running and is waiting for its parent to collect it.
Short answer: delivery is not exit
Four separate milestones sit behind “I killed it,” and kill -9 only guarantees the first:
| Milestone | What it means | What can delay it |
|---|---|---|
| 1. Signal sent | kill(2) returned success. That reports that sending worked, not that the target has terminated. |
Permissions: the sender needs the right identity or capability. |
| 2. Kernel wait ends or becomes interruptible | The task is runnable again and can notice the pending signal. | An uninterruptible wait for an event that hasn’t happened. |
| 3. Task acts on the fatal signal and exits | SIGKILL’s default action is “terminate.” | Step 2 not yet reached. |
| 4. PID is reaped | The parent has waited on it, so the entry leaves process listings. | A parent that hasn’t called wait. Until then the PID can remain as a zombie. |
The Linux man-pages signal(7) page lists SIGKILL with the default action “Term” and places it among the signals that cannot be caught or ignored. That describes the signal’s disposition in userspace. It does not say a task blocked deep in the kernel is yanked out at an arbitrary instruction.
Why a task can be unkillable for a while
The Linux kernel documentation on completions gives the clearest concrete case. By default, wait_for_completion() marks the calling task TASK_UNINTERRUPTIBLE and waits without a timeout. The documentation puts it this way: “The default behavior is to wait without a timeout and to mark the task as uninterruptible.” A task in that state is not woken by signals, so a pending SIGKILL waits until the awaited event occurs or the code path otherwise lets the task proceed.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
Kernel code uses this on purpose in places where bailing out halfway would leave data structures or hardware in an inconsistent state. The cost is that if the awaited event is slow or never comes, the task just sits there.
Not every “D” wait is identical
The same documentation describes other waiting modes:
- Interruptible variants return
-ERESTARTSYSif a signal is received. _killablevariants useTASK_KILLABLEand respond to fatal signals, again returning-ERESTARTSYSwhen interrupted.- The default variant is uninterruptible with no timeout.
So “D state” is a symptom label, not one exact behaviour. Whether a given process can be killed promptly depends on which wait it is in, which is a property of the specific driver, filesystem or kernel path. The completions documentation describes API behaviour; it is not a diagnosis for any particular filesystem, device driver or network mount, and it gives no typical duration.
The other “unkillable” case: zombies
A process shown as Z (defunct) is different. According to kill(2), an existing PID may belong to a zombie: a process that has finished executing but hasn’t yet been waited for by its parent. It is already dead, so there is nothing left to signal. It disappears when the parent reaps it, or when the parent itself exits and the process is adopted and reaped by another.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Quick distinction: D means the task is still alive and blocked in the kernel. Z means execution is over and only the bookkeeping entry remains.
What to check on a machine
These are general inspection steps, not a promise of a fix.
- Confirm the state:
ps -o pid,ppid,stat,wchan:32,cmd -p PID.Dmeans uninterruptible wait;Zmeans zombie. - If it is
Z, look at the parent (PPID). The fix lives with the parent: it needs to reap its children, or be restarted. - If it is
D, theWCHANcolumn hints at the kernel function the task is sleeping in. It often points toward the subsystem involved, such as storage or a network filesystem. - Look at what the task was doing: open files, mounts, and kernel log messages (
dmesg) for I/O errors or hung-task warnings. - Address the awaited event rather than the signal. If the cause is an unresponsive device or mount, restoring it is what lets the wait finish and the pending SIGKILL take effect.
Repeating kill -9 or waiting a fixed number of seconds is not guaranteed to change anything. The sources describe no universal duration, and a second SIGKILL is the same pending fatal signal.
A related example: the freezer
The kernel’s freezer documentation, which covers suspend and hibernation, shows how waits can depend on other tasks: an uninterruptible completion wait can stay blocked until a task it depends on is thawed. It illustrates that a blocked task may be waiting on another task rather than on hardware. It isn’t a diagnosis for any ordinary stuck process.
Best Value
What “can’t kill” really means
SIGKILL is not defeatable by the process itself. The accurate claim is narrower: a task in an uninterruptible kernel wait won’t disappear until that wait ends. No named statistic exists in the official kernel and manual-page sources for how often this happens or how long it lasts, so any figure you see quoted for that is unsourced.
For deeper reading, Robert Love’s Linux Kernel Development (3rd edition) discusses TASK_UNINTERRUPTIBLE and D-state processes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
