Process State Resolution

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. In the following section, the process

R, S, D, T, Z, X six states do a description.

PROCESS State CODES

Here is the different values that the S, stat and state output specifiers (header "Stat" or "s") would 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 a 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 (should never be seen)

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

reaped by its parent.

For BSD formats and when the STAT keyword are used,additional characters may be displayed:

< High-priority (not nice-to-other users)

N low-priority (Nice-to-other users)

L have pages locked to memory (for real-time and custom IO)

S is a session leader

L was multi-threaded (using Clone_thread, like NPTL pthreads do)

+ is in the foreground process group

I. Viewing the status of a process

1.1 Using the PS command

[[Email protected]]# 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_d001_xezf

3434 1 Ss Ora_s000_xezf

3436 1 Ss Ora_s001_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)

With the PS –l option, you get more detailed process information:

(1) F (Flag): A series of numbers and that represents the current state of the process. The meanings of these numbers are:

00: If displayed separately, indicates that the process has been terminated.

01: The process is part of the core process and resides in the system main memory. such as: Sched,vhand,bdflush.

02:parent is tracing process.

04:tracing Parent ' s signal has stopped the process; The parent is Waiting (Ptrace (S)).

10: The process goes into hibernation when the priority level is less than or equal to 25 o'clock, and it cannot wake with a signal, for example, while waiting for an inode to be created.

20: Process is loaded into main memory (primary memory)

40: The process is locked in main memory and cannot be replaced until the transaction is complete.

(2) Process status: S (state)

O: The process is running on the processor and this state has never been seen in the wood.

S: Sleep state (sleeping)

R: Waiting to Run (runable) R Running or runnable (on run queue) process is in run or ready state

I: Idle state (idle)

Z: Zombie Status (Zombie)

T: Tracking status (traced)

B: The process is waiting for more memory pages

D: Non-disruptive deep sleep, generally caused by IO, synchronous IO in the read or write operation, the CPU can not do other things, can only wait, then the process is in this state, if the program uses asynchronous IO, this state should be seldom seen

(3) C (CPU usage): Estimated CPU utilization

1.2 Using the S field in the top command

PID User pr ni virt res shr s%cpu%mem time+ command

11423 Oracle 0 627m 170m 168m R 9.0 4110:21 Oracle

3416 Oracle 0 650m 158m 138m S 0 8.4 0:07.12 Oracle

11167 Oracle 0 626m 151m 149m S 0 8.0 400:20.77 Oracle

11429 Oracle 0 626m 148m 147m S 0 7.9 812:05.71 Oracle

3422 Oracle 0 627m 140m 137m S 0 7.4 1:12.23 Oracle

1230 Oracle 0 639m 107m 96m S 0 5.7 0:10.00 Oracle

637 Oracle 0 629m 76m 73m S 0 4.0 0:04.31 Oracle

Two. Process Status description

2.1 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 to execute is defined as a ready state, both of which are unified to the Task_running state under Linux.

2.2 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.

2.3 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-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. However, the uninterruptible sleep state process does not accept any external signals, so it is not possible to kill these processes in the D state with kill, either "kill", "Kill-9″ or" Kill-15″, in which case An alternative approach is to reboot.

The process that is in the 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 seen by PS, and it means that there is probably an IO problem, It may be that the peripheral itself has failed, or it may be that the remote file system being mounted is inaccessible.

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.

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.

We can see if there is a process in the uninterruptible state by Procs B in the Vmstat command. The command can only display a quantity.

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

When the process is sleeping uninterruptibly, the signal would be a noticed when the process returns from the system call or Trap.

-This is the key. When 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 was trapped in the midst of a system call (usually a n I/O operation on a Device-thus the initial in the PS output).

Such a process cannot is killed-it would 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 T (task_stopped or task_traced): Pause or Trace status

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.

2.5 Z (Task_dead-exit_zombie): Exit status, Process becomes zombie process

In the state of the Linux process, the zombie process is a very special one, it is the process that has ended, but it is not removed from the process table. Too much will cause the entries in the process table to be full, causing the system to crash, rather than consuming other system resources.

It has given up almost all memory space, no executable code, no scheduling, just a location in the list of processes, a record of the process's exit status and other processes to collect, in addition, the zombie process no longer occupies any memory space.

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.

As the child process exits, the kernel sends a signal to its parent process to notify the parent process to "corpse". 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.

This signal is SIGCHLD by default, but can be set when a child process is created through the clone system call.

If his parent process does not install the SIGCHLD signal handler call wait or Waitpid () waits for the child process to end, and does not explicitly ignore the signal, then it remains in the zombie state and the child process's corpse (TASK_STRUCT) cannot be released.

If the parent process is finished, the Init process automatically takes over the subprocess and cleans it up, and it can be cleared. But if the parent process is a loop and does not end, then the child process will remain zombie state, which is why there are sometimes many zombie processes in the system.

When the process exits, it will host all its child processes to another process (making it a child of another process). The managed process may be the next process that exits the process group where the process is located, if one exists, or the 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 the descendants of the Init process);
2, in a dead loop waiting for its child process exit event, and call Waitid system call to complete the "corpse" work;

The init process will not be paused and 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.

Unix/linux ways to handle zombie processes:

The parent process number is found, then the parent process is killed, and then the child process (the zombie process) is managed to another process, such as the Init process, and the child process's corpse (task_struct) is freed by the Init process.

In addition to the status of the PS to view the Zombi process, you can also use the following command to view:

[Email protected] ~]$ Ps-ef|grep defun

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

Oracle 28330 28275 0 May18? 00:00:00 [Xsession] <defunct>

Zombie Process Workaround:

(1) Rewrite the parent process, after the child process died to the corpse.

The concrete approach is to take over the SIGCHLD signal. After the child process dies, the SIGCHLD signal is sent to the parent process, and after the parent process receives this signal, the waitpid () function is executed to corpse the child process. This is based on the principle that even if the parent process does not call wait, the kernel sends a SIGCHLD message to it, although the default processing is ignored, and if you want to respond to this message, you can set a handler function.

(2) Kill the parent process.

After the parent process dies, the zombie process becomes the "orphan process", and the adoptive process init,init will always be responsible for cleaning up the zombie process. All of the zombie processes it produces also disappear. Such as:

Kill-9 ' Ps-ef | grep "Process Name" | awk ' {print $} '
where "process name" is the process name in the zombie state.

(3) to kill the father process, try to use skill-t tty to close the corresponding terminal, TTY is the corresponding TTY number (terminal number) process. However, PS may not be able to find the TTY number for a particular process, and it will need to be judged by itself.
(4) Restart the system, which is one of the most commonly used methods.

2.6 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 process that has been detach in multithreaded programs. 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.

Three. Process status Change description

3.1 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, since the calling process is in the task_running state (otherwise, it is 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.

3.2 Process state changes

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.

When a process changes from a task_running state to a non-task_running state, there are two ways:
1, the response signal and enter the task_stoped state, or Task_dead state;
2. Perform a system call to actively enter the Task_interruptible state (such as a nanosleep system call), or Task_dead state (such as an exit system call), or to enter task_ because the resources required to execute the system call are not met A interruptible state or task_uninterruptible state (such as a select system call).
Obviously, both of these situations can only occur if the process is executing on the CPU.

Process State Resolution