Linux Process D State _ turn

Linux process Status: S (task_interruptible), interruptible sleep state.

A process in this state is suspended because it waits for a certain event to occur (such as waiting for a socket connection, waiting for a semaphore). The TASK_STRUCT structure of these processes is placed in the waiting queue for the corresponding event. When these events occur (triggered by an external interrupt or triggered by another process), one or more processes in the corresponding wait queue will be awakened.

With the PS command we will see that, in general, most of the processes in the process list are in the Task_interruptible state (unless the machine is under a high load). After all, the CPU is so one or two, the process is almost dozens of hundred, if not most of the process is in sleep, the CPU how to respond to come over.

Linux process Status: D (task_uninterruptible), non-interruptible sleep state.

Like the task_interruptible state, the process is asleep, but the process is non-disruptive at the moment. non-interruptible means that the CPU does not respond to interrupts from external hardware, but rather that the process does not respond to asynchronous signals.
In most cases, the process should always be able to respond to an asynchronous signal when it is in a sleep state. Otherwise you will be surprised to find that kill-9 unexpectedly kill a sleeping process! So we also understand why the process of PS command sees almost no task_uninterruptible state, but always task_interruptible state.

The significance of the existence of the task_uninterruptible state is that certain processing processes of the kernel cannot be interrupted. In response to an asynchronous signal, the program's execution process is inserted into a process to process the asynchronous signal (the inserted process may exist only in the kernel state, or may extend to the user state), and the original process is interrupted. (See the analysis of asynchronous interrupts in Linux cores)
when a process is operating on some hardware, such as a process invoking a read system call to a device file, and the read system call eventually executes to the corresponding device-driven code and interacts with the corresponding physical device, it may be necessary to use the Task_ The uninterruptible State protects the process from interruption in the process of interacting with the device, causing the device to fall into an uncontrolled state. in this case, the task_uninterruptible state is always very short-lived, which is largely impossible to capture via the PS command.

There are also task_uninterruptible states that are easily captured in Linux systems. After the vfork system call is executed, the parent process enters the task_uninterruptible state until the child process calls exit or EXEC (see Magic vfork).
You can get the process in the Task_uninterruptible state by using the following code:

#include    void Main () {  if (!vfork ()) sleep (+);  

Compile and run, then PS:

[Email protected]:~/test$ ps-ax | grep a\.  out  4371 pts/0    d+     0:xx ./a. Out  4372 pts/0     s+     0:   4374 pts/1    s+     0: grep A. Out

Then we can experiment with the power of the task_uninterruptible state. Regardless of kill or kill-9, this task_uninterruptible state of the parent process is still standing.

Why is the process placed in uninterruptible sleep state? Processes in the Uninterruptiblesleep state are usually waiting for IO, such as disk IO, network IO, other peripheral io, if the process is waiting for the IO to be unresponsive for a longer period of time, then it is unfortunate to be seen by PS, It also means that there is a good chance that there is a problem with the IO, either the peripheral itself is faulty or the remote file system mounted is inaccessible (the D state 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 Uninterruptiblesleep 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 Uninterruptiblesleep state, the IO request for the process can be satisfied by restoring the connection to the NFS volume. D state, often due to an I/O resource not being met, and waiting to be raised, in the kernel source code FS/PROC/ARRAY.C, its text is defined as "" D (disk sleep),/* 2 * * (so that D is originally the beginning of disk letter), corresponding to the include/linux/sched.h in the "#define TAS K_uninterruptible 2 ". For example, when the NFS server is closed, if the relevant directory is not umount in advance, the NFS client executes DF to hang up the entire login session, pressing CTRL + C, CTRL + Z is useless. Disconnect and then log in, perform PS AXF see just the DF process status bit has become D, kill-9 can not kill. The correct way to do this is to restore the NFS server immediately, again to provide services, just suspended DF process found its hard to wait for the resources, then complete the task, automatic extinction. If the NFS server is unable to recover the service, the relevant NFS mount entry in/etc/mtab should be removed before reboot, so that the system restart process hangs if the wait resource is not repeated when the reboot process calls Netfs stop.

Reference:

Http://os.51cto.com/art/201003/185722.html

Processing of Linux process status D and Z

Linux Process D status _ go