프로세스 상태(STAT)가 D로 표시되는 경우는 , 해당 프로세스가 "uninterruptible sleep" 상태임을 나타낸다. 이것은 일반적으로 I/O에 대해 대기하는 것으로 다른 어떤 일도 할 수 없는 것을 의미한다 - 심지어 죽는 것을 포함 - 해당 I/O operation이 완료되기 전까지는.
대개는 D 상태인 프로세스들은 operation이 완료되어 그들이 R/S에 돌아가기 전까지 아주 극히 작은 시간동안(a fraction of a second) 만 거기에 있게 된다. 경험에 따르면, 만일 프로세스가 D 상태에 빠져있다면, 그것은 연결될 수 없는 NFS나 다른 원격 파일시스템과 통신하려고 하고, 문제가 있는 하드 드라이브에 접근하려고 하거나, 또는 비정상적인 device 드라이버를 이용해 어떤 하드웨어를 사용하려고 할 때 가장 자주 발생한다.
그러한 경우에, 복구하고 프로세스가 죽도록 하는 유일한 방법은 fs/drive/hardware를 회복시켜 동작하도록 하여 I/O가 완료되도록 하거나 또는 포기하고 시스템을 reboot하는 방법이다.
NFS같은 특이한 경우에, mount가 결국에는 time out되어 (실패 코드를 가지고) I/O operation으로 부터 리턴할 수도 있다, 하지만 이것은 mount 옵션에 따라 다르며, NFS mounts에서는 계속 대기하는 것이 매우 일반적이다.
이것이 D 상태를 가진 프로세스와 zombie 프로세스가 다른 점이다.
또한 커널 버그로 인해 D에 빠지는 경우도 확인 할 수 있다.
어떤 상태인지 확인하려면 ps -o pid,wchan 1234 를 실행하라. 그러면 어떠한 커널에서 빠져있는 wait channel을 확인할 수 있다.
a process status (STAT) of D indicates that the process is in an "uninterruptible sleep" state. In real-world terms, this generally means that it's waiting on I/O and can't/won't do anything - including dying - until that I/O operation completes.
Processes in a D state will normally only be there for a fraction of a second before the operation completes and they return to R/S. In my experience, if a process gets stuck in D, it's most often trying to communicate with an unreachable NFS or other remote filesystem, trying to access a failing hard drive, or making use of some piece of hardware by way of a flaky device driver. In such cases, the only way to recover and allow the process to die is to either get the fs/drive/hardware back up and running so the I/O can complete or to give up and reboot the system. In the specific case of NFS, the mount may also eventually time out and return from the I/O operation (with a failure code), but this is dependent on the mount options and it's very common for NFS mounts to be set to wait forever.
This is distinct from a zombie process, which will have a status of Z.
A good way to see what's going on is to run ps -o pid,wchan 1234 (inserting the relevant pid), and that will tell you which wait channel it's stuck on in the kernel.