Linux process Status (PS stat) R, S, D, T, Z, X__linux

reproduced from: http://blog.csdn.net/brucexu1978/article/details/7721313
Linux process status (PS stat) R, S, D, T, Z, X
March 11, 2012 Posted by Jian
PS Progress Status: process state codesPROCESS State Codes
Here are the different values of that 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 then the STAT keyword is used, additional characters
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, ps parameter description

PS provides a number of option parameters, commonly used in the following:

l long format output;

U displays the process in the order of user name and start time;

J Use task format to display process;

F to display the process in a tree format;

A displays all processes for all users (including other users);

X shows the process of the uncontrolled terminal;

R shows the running process;

WW avoids detailed parameters being truncated;

Our common option is the combination of aux or lax, and the application of parameter F.

2, PS aux or lax output interpretation

The owner of the USER process;

The ID of the PID process;

PPID the parent process;

The percentage of CPU consumed by the%CPU process;

%mem the percentage of memory consumed;

The nice value of NI process, the value is large, indicating less CPU time;

VSZ process virtual size;

Number of pages in RSS hosting;

TTY Terminal ID

STAT process status (there are several)

D the dormant state (usually IO process) which cannot be interrupted;

R is running that can be done in a queue;

S in dormant state;

T stop or be traced;

W enters memory Exchange (invalid starting from kernel 2.6);

X dead process (never seen);

Z Zombie process;

High-priority Process <

N processes with lower priority

L Some pages are locked into memory;

The leader of the S process (under it there are sub processes);

L multi-process (using Clone_thread, similar to NPTL pthreads);

+ The process group located in the background;

Wchan is waiting for the process resources;

Start time of the process;

time when the process consumes CPU;

The name and parameters of command commands;

3 Use PS format output to view process status:
Ps-eo User,stat..,cmd

User username
UID User number
PID Process Number
Ppid Parent Process Number
Size memory, Kbytes bytes.
Vsize Total virtual memory size, Bytes bytes (contains code+data+stack)
Share Total shared pages
Nice process priority (default is 0, maximum is-20)
Priority (PRI) kernel scheduling priority
Percentage of physical memory shared by the PMEM process
TRS program execution code resident size
Total amount of physical memory used by the RSS process, Kbytes bytes
Time process execution up to now total CPU take-up
Stat process Status
CMD (args) a simple format for executing commands

Example:
View the uid,pid,stat,pri of the current system process, sorted by the UID number.
Ps-eo Pid,stat,pri,uid–sort UID

View the User,pid,stat,rss,args of the current system process, sorted by RSS.
Ps-eo User,pid,stat,rss,args–sort RSS

Linux is a multi-user, multitasking system, you can run multiple users at the same time multiple programs, it will inevitably produce a lot of processes, and each process will have a different state.

Linux process Status: R (task_running), executable state.

Only processes in this state can run on the CPU. At the same time, multiple processes may be in an executable state, and the TASK_STRUCT structure (Process Control block) of these processes is put into 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.

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, which is unified under Linux as a task_running state.

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 to connect, waiting for a semaphore). The TASK_STRUCT structure of these processes is placed in the wait 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 are awakened.

Through the PS command we will see that most of the processes in the process list are in task_interruptible state (unless the machine is heavily loaded). After all, the CPU is so one or two, the process of dozens of hundreds, if not most processes are in sleep, the CPU how to respond to come over.

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

Similar to the task_interruptible state, the process is asleep, but the process is not interrupted at the moment. Non-interruption means that the CPU does not respond to the interruption of external hardware, but that the process does not respond to asynchronous signals.
In most cases, when a process is asleep, it should always be able to respond to asynchronous signals. Otherwise you will be surprised to find that kill-9 could not kill a sleeping process. So we also understand very well, why the PS command to see the process will almost not appear task_uninterruptible state, but always task_interruptible state.

The significance of the task_uninterruptible state is that some processes of the kernel cannot be interrupted. If an asynchronous signal is responded to, the process of execution of the program is inserted into a procedure for processing the asynchronous signal (the inserted process may exist only in the kernel state, or it may extend to the user state), and the original process is interrupted. (see "Analysis of Linux kernel asynchronous interrupts")
When a process is operating on some hardware (for example, the process calls read system calls and reads 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 so that the process is interrupted by the process interacting with the device, causing the device to fall into a state of uncontrollable control. In this case the task_uninterruptible state is always very short, and the PS command is basically impossible to capture.

There are also task_uninterruptible states in the Linux system that are easily captured. After the vfork system call is performed, the parent process enters the task_uninterruptible state until the child process calls exit or exec (see "The Magic Vfork").
You can get a process in a task_uninterruptible state with the following code: #include void Main () {if (!vfork ()) sleep (100);}

Compile and run, then PS: kouu@kouu-one:~/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 test the power of the task_uninterruptible state. No matter kill or kill-9, the parent process of this task_uninterruptible state still stands.

Linux process Status: T (task_stopped or task_traced), paused status or trace state.

Sends a sigstop signal to the process, and it enters the task_stopped state because the signal should be signaled (unless the process itself is in a task_uninterruptible state and does not respond to the signal). (Sigstop, like the Sigkill signal, is very mandatory.) The user process is not allowed to reset the corresponding signal processing function through the Signal series system call. ）
Sends a sigcont signal to the process to restore it from the task_stopped state to the task_running state.

When a process is being tracked, it is in the special state of task_traced. "Being tracked" means that the process pauses and waits for the process that tracks it to operate on it. For example, in GdB, the next breakpoint on the tracked process is task_traced when the process stops at the breakpoint. At other times, the process being tracked is still in the state mentioned above.

For the process itself, the task_stopped and task_traced states are very similar, indicating that the process is paused.
And the task_traced state is equivalent to a layer of protection on the task_stopped, the process in the task_traced state can not respond to the sigcont signal and be awakened. The process that is being debugged can only be restored to the task_running state by waiting for the debugging process to perform Ptrace_cont, Ptrace_detach, and so on by Ptrace system calls (by specifying an operation by ptrace the parameters of the system call), or when the debug process exits.

Linux process Status: Z (Task_dead–exit_zombie), exit state, process becomes zombie process.

The process is in the Task_dead state during the exit process.

During this exit process, all resources that the process occupies will be reclaimed, except for the TASK_STRUCT structure (and a few resources). So the process is left only task_struct such an empty shell, so called zombies.
The reason for preserving task_struct is that the exit code for the process is stored in the task_struct, along with some statistical information. And the parent process is likely to be concerned about this information. For example, in a shell, the $? variable saves the exit code of the last exiting foreground process, and this exit code is often used as a condition of the IF statement.
Of course, the kernel can also store this information somewhere else and release the TASK_STRUCT structure to save some space. However, it is more convenient to use the TASK_STRUCT structure, since the lookup relationship from PID to Task_struct has been established in the kernel, as well as the parent-child relationship between processes. Releasing task_struct, you need to create a new data structure so that the parent process can find the exit information for its child processes.

The parent process can wait for a system call (such as WAIT4, Waitid) in the waiting series to await the exit of some or some of the child processes and obtain its exit information. The system call of the wait series will then also release the body of the subprocess (task_struct).
When a 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 you can set this signal when creating a subprocess through a clone system call.

The following code enables the process of creating a Exit_zombie state: #include void Main () {if (fork ()) while (1) sleep (100);

Compile and run, then PS: kouu@kouu-one:~/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

This zombie state's subprocess persists as long as the parent process does not exit. So if the parent process exits, who will "corpse" the child process.
When a process exits, all its child processes are hosted to another process (making it a subprocess of another process). entrusted to whom. It may be the next process (if any) of the process group where the process was exited, or the 1th process. So every process, every moment, has a parent process. Unless it's a number 1th process.

Process 1th, PID 1 process, also known as the init process.
Once the Linux system is started, the first created user state process is the INIT process. It has two missions:
1, execute system initialization script, create a series of processes (they are descendants of the Init process);
2, in a dead loop waiting for the child process of the exit event, and call the Waitid system call to complete the "corpse" work;
The init process will not be paused or killed (this is guaranteed by the kernel). It is in a 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 state, process is about to be destroyed.

The process may not retain its task_struct during the exit process. This process, for example, is a process that has been detach in a multithreaded program. Thread. See "Linux Threading Analysis"). or the parent process explicitly ignores the SIGCHLD signal by setting the handler of the SIGCHLD signal as sig_ign. (This is a POSIX rule, although the exit signal for a subprocess 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. So the Exit_dead state is very short and almost impossible to capture with the PS command.

The initial state of the process

Processes are created through system calls (fork, clones, vfork) of the Fork series, and the kernel (or kernel module) can also create kernel processes through the Kernel_thread function. The functions that create the subprocess essentially do the same thing--copy the calling process and get the child process. (You can determine whether the various resources are shared or private by option parameters.) ）
So now that the calling process is in the task_running state (otherwise, it is not running and how it is invoked.) , the child process defaults to the task_running state.
In addition, the clone_stopped option is also accepted in the call to the clone and kernel functions kernel_thread the system call, thus placing the initial state of the child process as task_stopped.

Process state Transition

After the process has been created, the state can change a series of changes until the process exits. While there are several kinds of process states, the process state changes in only two directions-from the task_running state to a task_running state, or from a non-task_running state to a task_running state.
That is, if you send a sigkill signal to a task_interruptible-state process, the process is awakened (into the task_running state) and then exits (into the Task_dead state) in response to the sigkill signal. does not exit directly from the task_interruptible state.

A process changes from a task_running state to a task_running state and is implemented by a wake operation by another process, or possibly an interrupt handler. The process setting that performs the wake-up is task_running the state of the wakeup process, and then its task_struct structure is added to the executable queue of a CPU. Then the awakened process will have the opportunity to be scheduled for execution.

And the process changes from task_running state to task_running state, there are two ways:
1, in response to the signal and into the task_stoped state, or Task_dead state;
2. Execute system call to enter task_interruptible state (such as Nanosleep system call), or Task_dead state (such as exit system call), or because the resources needed to execute system call are not satisfied, enter Task_ interruptible State or Task_uninterruptible state (such as select System Call).
Obviously, both of these situations can only occur if the process is executing on the CPU.

Kernel module code:
—————-killd.c —————-
#include #include #include//for_each_process
module_license ("BSD");
static int pid =-1;
Module_param (PID, int, s_irugo);
Static int killd_init (void)
{
struct task_struct * p;
Printk (Kern_alert "Killd:force D status process to Death\n ");
Printk (Kern_alert "killd:pid=%d\n", PID);
//read_lock (&tasklist_lock);
For_each_process (p) {
if (p->pid = = pid) {
Printk ("killd:found\n");
Set_task_state (P, task_stopped);
Printk (Kern_alert "Killd:aha, Dead already\n");
return 0;
}
}
Printk (' not found ');
//read_unlock (&tasklist_lock);
return 0;
}
static void Killd_exit (void)
{
Printk (kern_alert "killd:bye\n");
}
Module_init (Killd_init);
Module_exit (killd_exit);
-–makefile ————
Obj-m: = KILLD.O
Compile module
make-c yourkerneltree m= ' pwd ' modules
when inserting a module, you can convert it by providing the process number in the D state For stopped state, use ordinary kill can kill.
./insmod./killd.ko pid=1234