Linux Process Stuck in D State (Uninterruptible Sleep), How to Handle

A process stuck in D state (uninterruptible sleep) is waiting on a kernel-level operation, typically I/O — and critically, it genuinely cannot be killed with a normal kill or even kill -9 while in this state, since the process is inside the kernel and not currently responsive to any signal at all until that underlying kernel operation completes or fails.

The Problem

A process appears unresponsive, and attempting to terminate it has no effect:

ps aux | grep D
user  4521  0.0  0.1  ...  D    process_name

kill -9 4521
# process remains, still showing state D

Why It Happens

Linux processes in D state are waiting on a kernel-level operation that's specifically designed to not be interruptible by signals — historically, this is meant for operations that must run to completion for data integrity reasons (certain disk I/O operations, for example), where allowing a signal to interrupt midway could leave data or kernel state in an inconsistent condition. Common causes of a process getting stuck here for an extended period:

• A failing or failed physical disk, where I/O requests are issued but never complete or fail cleanly, leaving the process waiting indefinitely on hardware that isn't responding at all
• An NFS mount where the remote server has become unresponsive or unreachable, and the client is configured with hard mount semantics (the default, which retries indefinitely rather than failing) rather than soft mount semantics
• A kernel bug or driver issue causing an I/O operation to never properly complete or signal its completion back to the waiting process
• Extreme I/O contention or an overloaded storage subsystem causing requests to be queued for an unusually long time, though this typically resolves eventually rather than truly hanging forever

The Fix

First, identify what the process is actually waiting on, since this determines the appropriate fix:

cat /proc/4521/stack
# or, for more detail on what I/O the process is blocked on:
cat /proc/4521/wchan

This often reveals whether the process is waiting on disk I/O, network filesystem I/O, or another specific kernel subsystem, pointing toward the actual underlying resource causing the block.

If the process is stuck on an NFS mount specifically, check the NFS server's own health and connectivity — a genuinely unreachable or crashed NFS server, combined with default hard-mount semantics, is a very common cause of processes stuck in D state indefinitely:

showmount -e nfs-server-hostname

If the NFS server is confirmed unreachable and can't be quickly restored, and this is a recurring risk you want to mitigate going forward, consider remounting with soft and an appropriate timeo setting, which allows I/O operations to eventually fail with an error rather than blocking indefinitely — though be aware this tradeoff means genuinely transient NFS hiccups could also result in application-level I/O errors that hard mounts would have otherwise patiently waited through:

# /etc/fstab entry, adjusted for soft mount semantics
nfs-server:/export /mnt/nfs nfs soft,timeo=100,retrans=3 0 0

For a genuinely failing disk, check kernel logs for corroborating hardware error messages, which confirm the disk itself as the root cause rather than a software-level issue:

dmesg | grep -i "error\|fail" | tail -50

If disk errors are present, the process will likely remain stuck until the disk either recovers (unlikely for genuine hardware failure) or the system is rebooted — at which point addressing the actual failing hardware (replacing the disk, for genuinely failed hardware) is the real fix, since the stuck process itself is just a symptom.

Since kill -9 genuinely cannot terminate a process in D state, your only reliable recovery options when the underlying I/O truly never resolves are: waiting for the underlying resource (disk, NFS server) to become available again, allowing the kernel operation to finally complete or fail on its own; or, if the situation is unrecoverable and time-sensitive, rebooting the system, since a reboot forcibly terminates everything including processes stuck in D state, at the cost of losing any unsaved work from other processes as well.

Still Not Working?

If a process remains in D state for an extended period with no clear corresponding hardware or NFS issue you can identify, and a reboot isn't immediately practical, check whether the process is actually making very slow but genuine progress, rather than being truly stuck forever — extremely high I/O contention or an overwhelmed storage subsystem can produce very long, but not literally infinite, D-state waits. Monitoring actual I/O activity on the relevant device over an extended period (rather than concluding a hang after only a brief observation) can distinguish between "genuinely stuck forever" and "extremely, unacceptably slow but still eventually resolving," which point toward different appropriate next steps — the former toward hardware/NFS investigation, the latter toward addressing genuine I/O performance or capacity issues instead.