A process in state D ignores kill -9 — diagnose why and what to do
A backup job hangs and will not die. You try to kill it and it stays. Below is what the box shows. Explain what state the process is in, why SIGKILL has no effect, and what you can actually do about it.
$ ps -eo pid,ppid,stat,wchan,cmd | grep 4712
4712 1 D+ rwsem_down_read dd if=/dev/sdb of=/backup/img bs=4M
$ sudo kill -9 4712
$ ps -o pid,stat,cmd 4712
4712 D+ dd if=/dev/sdb of=/backup/img bs=4M # still here after SIGKILL
$ grep State /proc/4712/status
State: D (disk sleep)Diagnose the state and give the response.
D is uninterruptible sleep: the process is blocked inside a kernel call — here dd waiting on failing disk I/O. SIGKILL is queued but cannot be delivered until that syscall returns, so kill -9 does nothing while it hangs. You cannot force it dead; fix the underlying I/O (the sick device, an NFS mount, storage) so the call unblocks and it exits — otherwise reboot the host.
- ✗Trying harder with
kill -9when aDprocess cannot receive it yet - ✗Mistaking uninterruptible sleep for a zombie or a caught-signal handler
- ✗Ignoring the real cause — stuck disk, NFS, or block-device I/O
- →How would you find which device or mount the process is blocked on?
- →Why does the kernel use an uninterruptible sleep for some I/O at all?
Solution
1. Read the state
The STAT column shows D+ — uninterruptible sleep (D (disk sleep) in /proc/4712/status). The wchan field rwsem_down_read says the process is asleep in the kernel waiting on a lock/I/O. dd if=/dev/sdb is reading a sick device.
2. Why kill -9 is inert
$ sudo kill -9 4712 # signal is queued…
$ grep State /proc/4712/status
State: D (disk sleep) # …but not delivered: still in DSIGKILL is only delivered when the process returns from the kernel to user mode. While it hangs in uninterruptible sleep inside the syscall, the signal is never acted on — even kill -9 waits. This is not a zombie and not a caught signal: you cannot kill it now.
3. What to actually do
Fix the I/O cause: check dmesg for /dev/sdb errors, a hung NFS mount, or a failing controller. Once the call unblocks (returns or times out), the queued SIGKILL is delivered and the process dies. If the device is gone for good, a host reboot is the only remaining option.
