Linux process State Resolution R, S, D, T, Z, X

Linux is a multi-user, multi-tasking system that can run multiple user programs at the same time, which inevitably results in many processes, each of which has a different state.
Linux process Status:R (task_running), executable state.
Only processes in that state are likely to run on the CPU. At the same time, multiple processes may be in the executable state, and the TASK_STRUCT structure (Process Control block) of those processes is placed in the corresponding CPU's executable queue (a process can only appear in the executable queue of one CPU). The task of the Process scheduler is to select a process from each CPU's executable queue to run on that CPU separately.
Many operating system textbooks define a process that is executing on the CPU as a running state, while a process that is executable but not yet scheduled for execution is defined as a ready state.These two states are unified under Linux for the task_running state.
Linux process Status:S (task_interruptible), an interruptible sleep state.
The process in this state becausewait for a certain event to occur (such as waiting for a socket connection, waiting for a semaphore) and being suspended。 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-disruptive sleep state.
Like the task_interruptible state, the process is asleep, but the process is non-disruptive at the moment. Non-disruptive,It is not 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 thatKill-9 can't even 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 Linux kernel Asynchronous interrupt analysis) when a process is operating on some hardware (for example, a process calls 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), you may need 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 (100);}
Compile and run, then PS:
[Email protected]:~/test$ ps-ax | grep a\.out 4371 pts/0 D+ 0:00 ./a.out 4372 pts/0 S+ 0:00 ./a.out 4374 pts/1 S+ 0:00 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.
Linux process Status:T (task_stopped or task_traced), pause State or trace state.
sends a sigstop signal to the process, which enters the task_stopped state (unless the process itself is in task_uninterruptible state and does not respond to the signal) because it responds to the signal。 (Sigstop is very mandatory, as is the Sigkill signal.) The user process is not allowed to reset the corresponding signal handler function through the system call of the signal series. ）sends a sigcont signal to the process, allowing it to recover from the task_stopped state to the task_running state.
When the process is being traced, it is in the special state of task_traced. "Being traced" refers to a process that pauses and waits for the process that tracks it to operate on it. For example, in GdB, the next breakpoint on the tracked process, the process stops at the breakpoint at the time of the task_traced state. At other times, the tracked process is still in the States mentioned earlier.
For the process itself, the task_stopped and task_traced states are similar, indicating that the process is paused. While the task_traced state is equivalent to a layer of protection above the task_stopped, the process in task_traced state cannot respond to the sigcont signal and is awakened. The debugged process can only restore the task_running state until the debug process executes Ptrace_cont, Ptrace_detach, and so on through the PTRACE system call (by specifying the action by PTRACE the system call's parameters), or the debug process exits.
Linux process Status:Z (Task_dead-exit_zombie), exit status, process becomes zombie process.
The process is in the Task_dead state during the exit process.
In this exit process, all the resources that the process occupies will be recycled, in addition to the TASK_STRUCT structure (and a few resources). So the process only left task_struct such an empty shell, so called zombies. The reason for the retention of task_struct is that the exit code of the process, as well as some statistical information, are stored in task_struct. And its parent process is likely to be concerned about this information. In the shell, for example, the $ variable saves the exit code for the last exiting foreground process, and this exit code is often used as a condition for the IF statement. Of course, the kernel can also store this information elsewhere, freeing the task_struct structure to save some space. However, the use of the TASK_STRUCT structure is more convenient because the kernel has established a relationship between the PID and the Task_struct lookup, as well as the parent-child relationship between processes. Releasing the task_struct, you need to create some new data structures so that the parent process can find the exit information for its child processes.
The parent process can wait for the exit of one or some of the child processes through a system call to the wait series, such as WAIT4, Waitid, and get its exit information. Then the system call of the wait series will also release the Corpse (task_struct) of the child process. As the child process exits, the kernel sends a signal to its parent process to notify the parent process to "corpse". This signal is SIGCHLD by default, but can be set when a child process is created through the clone system call.
The following code enables the creation of a Exit_zombie State process:
#include void Main () {if (fork ()) while (1) sleep (100);}
Compile and run, then PS:
[Email protected]:~/test$ ps-ax | grep a\.out 10410 pts/0 S+ 0:00 ./a.out 10411 pts/0 Z+ 0:00 [a.out] 10413 pts/1 S+ 0:00 grep a.out
the child process of this zombie state persists as long as the parent process does not exit. So if the parent process exits, who is going to "corpse" the child process? When the process exits, it will host all its child processes to another process (making it a child of another process). Who's hosting it for? It may be the next process that exits the process group where the process is located, if one exists, or the number 1th process. So every process, every moment, has a parent process present. Unless it is process number 1th.
Process 1th, PID 1, also known as the init process. After the Linux system is started, the first user-state process created is the INIT process. It has two missions: 1. Execute the System initialization script, create a series of processes (they are descendants of the init process), 2, wait for the exit event of its child process in a dead loop, and call the Waitid system call to complete the "corpse" work; the init process is not paused, Will not be killed (this is guaranteed by the kernel). It is in the task_interruptible state while waiting for the child process to exit, while the "corpse" process is in the task_running state.
Linux process Status:X (Task_dead-exit_dead), exit status, process is about to be destroyed.
The process may also not retain its task_struct during the exit process. For example, this process is a detach process in a multithreaded program (process?). Thread? See "Linux Threading Analysis"). or the parent process explicitly ignores the SIGCHLD signal by setting the handler of the SIGCHLD signal to sig_ign. (This is the POSIX rule, although the exit signal for a child process can be set to a signal other than SIGCHLD.) At this point, the process is placed in the Exit_dead exit state, which means that the next code immediately releases the process completely. So the Exit_dead state is very short and almost impossible to capture via the PS command.
Initial state of the process
The process is created through the system calls of the Fork series (fork, clone, Vfork), and the kernel (or kernel module) can also create kernel processes through the Kernel_thread function. The functions that create child processes essentially do the same thing-copying the calling process to get the child process. (You can use option parameters to determine whether a variety of resources is shared or private.) So now that the calling process is in the task_running state (otherwise, it's not running, how does it make the call?). ), the child process is also in the Task_running state by default. In addition, the system call to clone and kernel function Kernel_thread also accepts the clone_stopped option, which resets the initial state of the child process to task_stopped.
Process state Change
After the process has been created, the state may change a series of changes until the process exits. While there are several process states, the process state changes in only two directions-from the task_running state to a non-task_running state, or from a non-task_running state to a task_running state. That is, if a sigkill signal is sent to a task_interruptible state process, the process will first be awakened (into the task_running state) and then exited (into a task_dead state) in response to the sigkill signal. does not exit directly from the task_interruptible state.
The process changes from a non-task_running state to a task_running state, and is implemented by a wake-up operation from another process (or possibly an interrupt handler). The process setting that wakes up is task_running the state of the wake process, and then joins its task_struct structure to the executable queue of a CPU. The awakened process will then have the opportunity to be dispatched for execution.
And the process from the task_running state to non-task_running state, there are two ways: 1, the response signal to enter the task_stoped state, or Task_dead State; 2, the execution system calls active into Task_ A interruptible state (such as a nanosleep system call), or Task_dead state (such as an exit system call), or a task_interruptible state or task_ because the resources required to perform the system call are not met Uninterruptible state (such as select System Call). Obviously, both of these situations can only occur if the process is executing on the CPU.

Three basic states of the process
The process constantly changes its running state while it is running. Typically, a running process must have the following three basic states.
Ready status
When a process is assigned to all the necessary resources except the CPU, the process state is called the ready state as long as the processor is available for immediate execution.
Execution (Running) state when a process has been acquired by a processor and its program is executing on a processing machine, the status of the process is called the execution state.
A process that is executing in a blocking (Blocked) state that, because it cannot be executed while waiting for an event to occur, discards the processor and is in a blocking state. There can be a number of events that cause a process to block, such as waiting for I/O to complete, requesting a buffer not satisfying, waiting for a letter (signal), etc.
2. Transitions between three states of the process

A process is constantly transitioning from one state to another while it is running, it can be in the ready state and execution state more than once, or it can be blocked multiple times. Figure 3_4 describes the three basic states of the process and their transformations.
(1) Ready → Executes the process in the ready state, and when the process dispatcher assigns it a processor, the process is transformed from the ready state to the execution state.
(2) execution → Ready in the execution of the process during its execution, because a time slice allocated to it has been exhausted and had to give up the processor, so the process from the execution state into a ready state.
(3) execution → blocking the executing process from execution state to blocking state as it waits for an event to occur and cannot continue execution.
(4) blocking → ready to block the process, if its waiting for the event has occurred, then the process from the blocking state into a ready state.

Linux process State Resolution R, S, D, T, Z, X