Detailed parsing of linux Process status

Article Title: details about linux Process status. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

The current time-sharing operating system can run multiple programs on a single CPU, making these programs seem to be running at the same time. Linux is such an operating system.

In linux, each running program instance corresponds to one or more processes. The Linux kernel needs to manage these processes so that they can run simultaneously in the system. The Linux kernel manages processes in two aspects: Process status management and process scheduling. This topic describes Process status management.

Process status

In linux, we can use the ps command to view the processes in the system and their statuses:

R (TASK_RUNNING), the executable status.

Only processes in this status can run on the CPU. Multiple processes may be executable at the same time. The task_struct structure of these processes (Process Control Block) put into the executable queue of the corresponding CPU (a process can only appear in the executable queue of one CPU ). The task of the Process scheduler is to select a process from the executable queue of each CPU to run on this CPU.

As long as the executable queue is not empty, the CPU corresponding to it cannot be lazy and a process must be executed. Generally, the CPU is "busy ". Correspondingly, the CPU "idle" means that the corresponding executable queue is empty, so that the CPU has nothing to do.

Someone asked why the dead loop program causes high CPU usage? Because the endless loop program is basically in the TASK_RUNNING State (the process is in an executable Queue ). Unless in some extreme situations (such as a serious shortage of system memory, some pages to be used by the process are swapped out, and the pages cannot be allocated to memory when they need to be swapped in ......), Otherwise, the process will not sleep. Therefore, the CPU executable queue is always not empty (at least such a process exists), and the CPU will not be "idle ".

Many operating system textbooks define the processes being executed on the CPU as RUNNING, while the processes that can be executed but have not been scheduled as READY, these two statuses are in the TASK_RUNNING state in linux.

S (TASK_INTERRUPTIBLE), an interrupted sleep state.

A process in this status is suspended because it waits for the occurrence of a certain event (such as waiting for socket connection or semaphore. The task_struct structure of these processes is put into the wait queue of corresponding events. When these events occur (triggered by external interruptions or by other processes), one or more processes in the corresponding waiting queue will be awakened.

The ps command shows that the vast majority of processes in the process list are in the TASK_INTERRUPTIBLE state (unless the machine has a high load ). After all, there are one or two CPUs and hundreds of processes. if not most processes are sleeping, how can the CPU respond.

D (TASK_UNINTERRUPTIBLE.

Like TASK_INTERRUPTIBLE, the process is in sleep state, but the process cannot be interrupted at the moment. Non-disruptive means that the CPU does not respond to external hardware interruptions, but that the process does not respond to asynchronous signals.

In most cases, when a process is sleeping, it should always be able to respond to asynchronous signals. Otherwise, you will be surprised to find that kill-9 is not killing a sleeping process! As a result, we also understand why the ps command shows almost no TASK_UNINTERRUPTIBLE status for the process, but always TASK_INTERRUPTIBLE status.

The significance of the TASK_UNINTERRUPTIBLE status lies in that some kernel processing processes cannot be interrupted. If an asynchronous signal is returned, a program is inserted into the execution process to process the asynchronous signal. (The inserted process may only exist in the kernel state, it may also extend to the user State), so the original process is interrupted.

When a process operates on certain hardware (for example, a process calls the read system call to read a device file, and the read system call finally executes the code of the corresponding device driver, and interact with the corresponding physical device), you may need to use the TASK_UNINTERRUPTIBLE status to protect the process, so as to prevent the process of interaction between the Process and the device from being interrupted, causing the device to fall into an uncontrollable state. In this case, the status of TASK_UNINTERRUPTIBLE is always very short, and it is basically impossible to capture it through the ps command.

In linux, TASK_UNINTERRUPTIBLE is easily captured. After the vfork system is called, the parent process enters the TASK_UNINTERRUPTIBLE State until the child process calls exit or exec (see magic vfork).

The following code can be used to obtain a process in the TASK_UNINTERRUPTIBLE state:

# Include

Void main (){

If (! Vfork () sleep (100 );

}

Compile and run the program. ps:

Kouu @ kouu-one :~ /Test $ ps-ax | grep a \. out

4371 pts/0 D +./a. out

4372 pts/0 S +./a. out

4374 pts/1 S + grep a. out

Then we can test the power of the TASK_UNINTERRUPTIBLE status. Whether killed or killed-9, the parent process in the TASK_UNINTERRUPTIBLE status still stands.

T (TASK_STOPPED or TASK_TRACED), paused or tracked.

When a SIGSTOP signal is sent to a process, it enters the TASK_STOPPED status because it responds to the signal (unless the process itself is in the TASK_UNINTERRUPTIBLE status and does not respond to the signal ). (The SIGSTOP signal is the same as the SIGKILL signal, which is very mandatory. User processes are not allowed to reset the corresponding signal processing functions through system calls of the signal series .)

Send a SIGCONT signal to the process to restore it from the TASK_STOPPED status to the TASK_RUNNING status.

When a process is being tracked, it is in the special state of TASK_TRACED. "Being tracked" means that the process is paused and is waiting for the process to be tracked to operate on it. For example, in gdb, a breakpoint is placed on the tracked process, and the process is in the TASK_TRACED state when it stops at the breakpoint. At other times, the tracked process is still in the aforementioned state.

[1] [2] Next page