The "Uninterruptible" Hang
There is one process state that strikes fear into experienced sysadmins: Uninterruptible Sleep, marked as D in ps and top.
When a process needs to perform certain hardware operations — particularly direct disk I/O or specific network filesystem calls — it enters a state where it absolutely cannot be interrupted midway. Interrupting these operations could leave kernel data structures in an inconsistent state, causing corruption. So the kernel puts the process into D-state for the duration.
The critical property: A process in D-state cannot receive signals. This means:
kill -15 <pid>(SIGTERM) — ignored.kill -9 <pid>(SIGKILL) — also ignored.
The process will not wake up until the hardware operation completes (or times out). You cannot force it to exit.
What D-state tells you in practice:
| Observation | Likely Cause |
|---|---|
| Many processes in D-state, disk I/O high | Local disk saturation or failure |
| Many processes in D-state, disk I/O low | NFS/network filesystem hang or timeout |
| Single process in D-state briefly | Normal — transient I/O wait |
| Single process in D-state for minutes | Storage device or driver issue |
If your system is full of D-state processes and the storage subsystem is unresponsive, the only reliable recovery is often a reboot. This is why NFS mounts should use the soft and timeo options in production — a hard NFS mount will keep processes in D-state indefinitely if the server disappears.
A classic SRE interview question: "A process is consuming no CPU but kill -9 won't kill it. What's happening?" The answer is D-state (Uninterruptible Sleep). The process is blocked on a kernel I/O operation and cannot receive signals until the operation completes or the kernel times it out. Follow up: check dmesg for storage errors, check iostat for I/O saturation, and check if it's an NFS mount with mount | grep nfs.