Uninterruptible Sleep (D) status "Go" for Linux processes

Transferred from: http://c20031776.blog.163.com/blog/static/68471625201121522824111/

Some of the processes running in the KVM virtual machine are suddenly out of the question, and the problematic process cannot be killed with kill, and using PS you can see that these processes are in the D state:

[[email protected] ~]$ ps-a-ubuild-o pid,ppid,stat,command    pid  ppid Stat command  17009     1 Ds   -bash  17065     1 d    ls--color=tty-al  17577     1 D    /usr/java/jdk1.5.0_17/bin/java-xmx512m-classpath /usr/local/a  17629     1 D    /usr/java/jdk1.5.0_17/bin/java-xmx512m-classpath/usr/local/a

PS's manual says that the D state is the uninterruptible Sleep,linux process has two sleep states, a interruptible sleep, in which the process can be awakened by signaling it, For example, send Hup signal to Nginx master process can let Nginx reload the configuration file without restarting the nginx process, another sleep state is uninterruptible sleep, in this state of the process does not accept any foreign signal, That's why I couldn't kill the D-state process with kill, either "kill", "Kill-9″ or" Kill-15″, because they were not at all dictated by these signals.

Why is the process placed in uninterruptible sleep state? The process in uninterruptible sleep state is usually waiting for IO, such as disk IO, network IO, other peripheral io, if the process is waiting for the IO to not respond for a long time, then it is very unfortunate to be seen by PS, It also means that there is a good chance that there is a problem with the IO, it may be that the peripheral itself has failed, or it may be that the remote file system mounted is inaccessible, and the problem I encountered here is caused by the down NFS server.

It is because of not the corresponding IO, the process has entered the uninterruptible sleep state, so in order to restore the process from the uninterruptible sleep state, you have to make the process waiting for IO recovery, For example, if the NFS volume from a remote mount is inaccessible causing the process to enter the uninterruptible sleep state, the IO request of the process can be satisfied by restoring the connection to the NFS volume, in addition to To get rid of the D-State process, you can only restart the entire Linux system.

See someone say that if you want to kill the D-state process, usually can go to kill its parent process (usually the shell, I understand this situation is directly under the shell of the process, then the process into the D state), so I did, and then there is the above state: their father process was killed, But their parent process PID becomes 1, which is the init process, what can be good? At this time I have these D-state processes have affected the operation of some other processes, and the unreachable NFS volume can not be recovered within a period of time, then, had to restart, root is not the Jade Emperor, there is frustration.

Talk about this with Czhang, think that Linux if there is such a dedicated garbage collection process is good: the system automatically or the user manually put the zombie process, and such as I encountered before the D-State process Ppid set as the garbage collection process, then by killing this garbage collection process to clean up the zombies, How nice it should be ...

Uninterruptible Sleep (D) status "Go" for Linux processes