Linux Process status

Linux is a multi-user, multi-task system. If you can run multiple programs of multiple users at the same time, many processes will inevitably be generated, and each process will have different states. In the following sections

The following describes the six States: R, S, D, T, Z, and X.

Process State Codes

Here are the different values that the S, stat and state output specifiers (Header "stat" or "S") will display to describe the state of a process.

D uninterruptible sleep (usually Io)

R running or runnable (on run Queue)

S interruptible sleep (waiting for an event to complete)

T stopped, either by a job control signal or because it is being traced.

W paging (not valid since the 2.6.xx kernel)

X dead (shocould never be seen)

Z defunct ("zombie") process, terminated but not

Reaped by its parent.

For BSD formats and when the stat keyword is used, additional characters may be displayed:

<High-priority (not nice to other users)

N low-priority (nice to other users)

L has pages locked into memory (for real-time and custom Io)

S is a session leader

L is multi-threaded (using clone_thread, like nptl pthreads do)

+ Is in the foreground Process Group

1. view the process status

1.1 Use the ps command

[Root @ localhost] # ps-a-o PID, ppid, stat, command-u Oracle

PID ppid STAT command

637 1 ss oraclexezf (local = No)

729 1 ss oraclexezf (local = No)

1144 1103 S + TOP

1230 1 ss oraclexezf (local = No)

1289 1145 S + vmstat 10

1699 1 ss oraclexezf (local = No)

1827 1294 R + PS-a-o PID, ppid, stat, command-u Oracle

3410 1 ss ora_pmon_xezf

3412 1 ss ora_psp0_xezf

3414 1 ss ora_mman_xezf

3416 1 ss ora_dbw0_xezf

3418 1 ss ora_lgwr_xezf

3420 1 ss ora_ckpt_xezf

3422 1 ss ora_smon_xezf

3424 1 ss ora_reco_xezf

3426 1 ss ora_mmon_xezf

3428 1 ss ora_mmnl_xezf

3430 1 ss ora_d000_xezf

3432 1 ss ora_d0020.xezf

3434 1 ss ora_s000_xezf

3436 1 ss ora_s0020.xezf

3438 1 ss ora_s002_xezf

3488 1 SSL/home/oracle_app/bin/tnslsnr listener-inherit

11167 1 ss oraclexezf (local = No)

11423 1 ss oraclexezf (local = No)

11425 1 ss oraclexezf (local = No)

11429 1 ss oraclexezf (local = No)

14867 1 ss oraclexezf (local = No)

19323 1 ss oraclexezf (local = No)

Use the-L option of PS to obtain more detailed process information:

(1) f (FLAG): The sum of a series of numbers, indicating the current state of the process. The meanings of these numbers are:

00: If it is displayed separately, the process has been terminated.

01: A process is a part of the core process and resident in the main memory of the system. Such as sched, vhand, and bdflush.

02: parent is tracing process.

04: Tracing parent's signal has stopped the process; the parent is waiting (ptrace (s )).

10: when the priority of a process is lower than or equal to 25, it enters the sleep state and cannot be awakened by a signal, for example, waiting for an inode to be created.

20: The process is loaded into the primary memory (primary memory)

40: The process is locked in the primary memory and cannot be replaced before the transaction is completed.

(2) Process status: S (state)

O: the process is running on the processor. This status has never been seen before.

S: Sleeping)

R: Waiting for running (runable) r running or runnable (on run Queue) the process is in the running or ready state.

I: idle)

Z: Zombie)

T: trace status (traced)

B: The process is waiting for more memory pages.

D: uninterrupted deep sleep, usually caused by I/O. When synchronous I/O is performing read or write operations, the CPU cannot do other tasks and can only wait. At this time, the process is in this State, if the program uses asynchronous Io, this State should be rarely seen.

(3) c (CPU usage): estimated CPU usage

1.2 use the s field in the top Command

PID user PR Ni virt res shr s % CPU % mem time + command

11423 Oracle 16 0 627 M 170 m 168 M r 32 9.0 4110: 21 Oracle

3416 Oracle 15 0 650 m 158 M 138 m s 0 8.4. 12 Oracle

11167 Oracle 15 0 626 m 151 m 149 m s 0 8.0: 400 Oracle

11429 Oracle 15 0 626 m 148 M 147 m s 0 7.9: 812 Oracle

3422 Oracle 18 0 627 M 140 m 137 m s 0 7.4. 23 Oracle

1230 Oracle 15 0 639 M 107 M 96 m s 0 5.7. 00 Oracle

637 Oracle 15 0 629 M 76 m 73 m s 0 4.0. 31 Oracle

2. Process status description

2.1 R (task_running): 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.

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.

2.2 S (task_interruptible): interrupted sleep status

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.

2.3 D (task_uninterruptible): uninterrupted sleep

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. However, uninterruptible sleep state processes do not accept any external signals, so they cannot use kill to kill these processes in D State, whether it is "kill ", "Kill-9" or "Kill-15". In this case, reboot is an optional method.

Processes in the Uninterruptible sleep state are usually waiting for Io, such as disk Io, network Io, and other peripheral Io. If the IO that the process is waiting for does not respond for a long time, so we can see it by PS, which means there may be Io problems, maybe the peripherals themselves are faulty, or, for example, the mounted remote file system is no longer accessible.

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.

We can use B in procs IN THE vmstat command to check whether there are uninterruptible processes. This command can only display the quantity.

In computer operating systems terminology, a sleeping process can either be interruptible (woken via signals) or uninterruptible (woken explicitly ). an uninterruptible sleep state is a sleep state that cannot handle a signal (such as waiting for disk or network io (input/output )).

When the process is sleeping uninterruptibly, the signal will be noticed when the process returns from the system call or trap.

-- This sentence is the key. When the job is in the uninterruptibly sleep state, signal is notified only when the process returns from the system call.

A process which ends up in "D" State for any measurable length of time is trapped in the midst of a System Call (usually an I/O operation on a device-thus the initial in the PS output ).

Such a process cannot be killed-It wowould risk leaving the kernel in an inconsistent state, leading to a panic. in general you can consider this to be a bug in the device driver that the process is accessing.

2.4 Tb (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.

For the process itself, the status of task_stopped is similar to that of task_traced, indicating that the process is paused.
In the task_traced state, the protection layer is added to the task_stopped state. A process in the task_traced state cannot be awakened when it responds to the sigcont signal. The debugged process can be restored to the task_running State only when the debugging process performs operations such as ptrace_cont and ptrace_detach through the ptrace System Call (the operation is specified through the parameters called by the ptrace system), or when the debugging process exits.

2.5 Z (task_dead-exit_zombie): The process is exited and becomes a zombie process.

In the status of a Linux Process, a zombie process is a very special process that has ended but has not been deleted from the Progress table. If there are too many entries in the table, the system crashes and other system resources are not occupied.

It has abandoned almost all the memory space, no executable code, and cannot be scheduled. It only keeps a location in the process list, logs the exit status of the process and other information for other processes to collect. In addition, the zombie process no longer occupies any memory space.

The process is in the task_dead status when it exits. During this exit process, all resources occupied by the process will be reclaimed, except for the task_struct structure (and a few resources. As a result, the process has only such an empty shell as task_struct, so it is called a zombie.

Task_struct is retained because the process exit code and some statistics are saved in task_struct. The parent process may be concerned with this information. For example, in shell, $? The variable stores the exit code of the Last Exit foreground process, which is often used as the judgment condition of the IF statement.
Of course, the kernel can also save this information elsewhere and release the task_struct structure to save some space. However, it is more convenient to use the task_struct structure, because the search relationship from PID to task_struct has been established in the kernel, as well as the parent-child relationship between processes. To release task_struct, you need to create a new data structure so that the parent process can find the exit information of its child process.

When a child process exits, the kernel sends a signal to its parent process to notify the parent process to "collect dead ". The parent process can wait for the exit of a child or child process and obtain its exit information through wait system calls (such as wait4 and waitid. Then the wait system calls will release the child process bodies (task_struct) by the way.

This signal is sigchld by default, but you can set this signal when creating a sub-process by calling the clone system.

If the parent process does not have the sigchld signal processing function that calls wait or waitpid () and waits for the child process to end, and does not explicitly ignore the signal, it will remain zombie, the bodies of sub-processes (task_struct) cannot be released.

If the parent process ends at this time, the INIT process will automatically take over the child process and collect the corpse for it. It can still be cleared. However, if the parent process is a loop and does not end, the child process will remain zombie, which is why many zombie processes sometimes exist in the system.

When a process exits, it will host all its sub-processes to other processes (making them sub-processes of other processes ). The managed process may be the next process (if any) that exits the process group where the process is located, or process 1. Therefore, every process and every moment has a parent process. Unless it is a process no. 1. Process 1, a process whose PID is 1, also known as the INIT process.

After Linux is started, the first user-state process created is the INIT process. It has two missions:
1. Execute the system initialization script to create a series of processes (all of them are descendants of the INIT process );
2. Wait for the exit event of its child process in an endless loop and call the waitid system call to complete the "zombie" operation;

The INIT process will not be paused or killed (this is guaranteed by the kernel ). It is in the task_interruptible status while waiting for the sub-process to exit, while the "zombie" process is in the task_running status.

Unix/Linux:

Find the parent process number and kill the parent process. Then, the child process (zombie process) will be hosted in other processes, such as the INIT process, and then the INIT process will take the child process's body (task_struct) release.

In addition to viewing the zombi process through the PS status, you can also run the following command to view it:

[Oracle @ Rac1 ~] $ PS-Ef | grep defun

Oracle 13526 12825 0 00:00:00 pts/1 grep defun

Oracle 28330 28275 0 may18? 00:00:00 [xsession] <defunct>

BotNet solution:

(1) rewrite the parent process and send it to the dead after the child process is dead.

The specific method is to take over the sigchld signal. After a child process dies, it sends a sigchld signal to the parent process. After receiving the signal, the parent process executes the waitpid () function to collect the child process. This is based on the principle that even if the parent process does not call wait, the kernel will send sigchld messages to it, even though the default processing is ignored. If you want to respond to this message, you can set a processing function.

(2) Kill the parent process.

After the death of the parent process, the zombie process becomes an "orphan process". After it passes through to the INIT process on process 1, init will always be responsible for cleaning up the zombie process. All the zombie processes it generates will also disappear. For example:

Kill-9 'ps-Ef | grep "process name" | awk '{print $3 }''
"Process name" indicates the process name in zombie state.

(3) If the parent process cannot be killed, try to use skill-T tty to close the corresponding terminal. tty is the corresponding tty (terminal number) of the process ). However, the PS may not be able to find the TTY number of a specific process, and you need to determine it by yourself.
(4) restart the system, which is also one of the most common methods.

2.6 x (task_dead-exit_dead): The process is about to be destroyed.

The process may not keep its task_struct during exit. For example, this process is a process that has been detach in a multi-threaded program. Or the parent process explicitly ignores the sigchld signal by setting the handler of the sigchld signal to sig_ign. (This is POSIX, although the exit signal of the sub-process can be set to a signal other than sigchld .)
At this point, the process will be placed in the exit_dead exit state, which means that the next code will immediately release the process completely. Therefore, the exit_dead status is very short, and it is almost impossible to capture it through the ps command.

Iii. Description of Process status changes

3.1 initial Process status

Processes are created through fork system calls (fork, clone, and vfork). The kernel (or kernel module) can also create kernel processes through the kernel_thread function. The functions used to create sub-processes are essentially the same-copy the calling process to obtain the sub-process. (You can use option parameters to determine whether resources are shared or private .)
Now that the calling process is in the task_running state (otherwise, if it is not running, how can it be called ?), The sub-process is also in the task_running status by default.
In addition, the clone_stopped option is also accepted when the system calls clone and kernel function kernel_thread, so that the initial state of the sub-process is set to task_stopped.

3.2 Process status change

After a process is created, its status may change until the process exits. Although there are several process statuses, there are only two directions for Process status change-from task_running to non-task_running, or from non-task_running to task_running.
That is to say, if a process in the task_interruptible State sends a sigkill signal, the process will first be awakened (into the task_running State), and then exit (into the task_dead State) in response to the sigkill signal ). It does not exit directly from the task_interruptible status.

A process changes from a non-task_running state to a task_running state, which is implemented by other processes (or possibly interrupt the processing program) Performing the wake-up operation. Set the status of the wake-up process to task_running and add its task_struct structure to the executable queue of a CPU. The wake-up process will have the opportunity to be scheduled for execution.

The process changes from the task_running status to the non-task_running status, there are two ways:
1. The response signal enters the task_stoped or task_dead status;
2. Execute the system call to actively enter the task_interruptible status (such as nanosleep System Call), or task_dead status (such as exit system call); or because the resources required for executing the system call are not satisfied, the status changes to task_interruptible or task_uninterruptible (for example, the Select system call ).
Obviously, both cases can only happen when the process is being executed on the CPU.