Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to look at the status of the Centos process". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

It is well known that today's time-sharing operating system can run multiple programs on a single CPU, making them appear to be running at the same time. Linux is such an operating system.

In a linux system, each running program instance corresponds to one or more processes. The linux kernel needs to manage these processes so that they run "simultaneously" on the system. This management of processes by the linux kernel is divided into two aspects: process state management and process scheduling.

Process status

Under linux, we can see the processes that exist in the system and their status through the ps command:

R (TASK_RUNNING), executable state.

Only processes in this state can run on CPU. At the same time, there may be multiple processes in the executable state, and the task_struct structure (process control block) of these processes is put into the executable queue of the corresponding CPU (a process can only appear in the executable queue of one CPU at most). The task of the process scheduler is to select a process from the executable queue of each CPU to run on that CPU.

As long as the executable queue is not empty, its corresponding CPU cannot be lazy and one of the processes will be executed. CPU is generally called "busy" at this time. Correspondingly, CPU "idle" means that its corresponding executable queue is empty, so that CPU has nothing to do.

Some people ask, why do dead-loop programs cause high CPU usage? Because the endless loop program is basically always in the TASK_RUNNING state (the process is in the executable queue). Unless there are some very extreme cases (such as a severe shortage of system memory, which causes some pages that the process needs to use to be swapped out and cannot be allocated to memory when the pages need to be swapped in. Otherwise, the process will not sleep So the executable queue for CPU is always not empty (at least one process exists), and CPU is not "idle".

Many operating system textbooks define processes that are executing on CPU as RUNNING states, while processes that can be executed but have not been scheduled for execution are defined as READY states. These two states are unified as TASK_RUNNING states under linux.

S (TASK_INTERRUPTIBLE), interruptible sleep state.

A process in this state is suspended because it is waiting for something to happen (such as waiting for a socket connection, waiting for a semaphore). The task_struct structures of these processes are placed in the waiting queue for the corresponding events. When these events occur (triggered by an external interrupt or by another process), one or more processes in the corresponding waiting queue will be awakened.

We can see from the ps command that, in general, the vast majority of processes in the process list are in the TASK_INTERRUPTIBLE state (unless the machine is heavily loaded). After all, there are only one or two CPU, and there are often dozens or hundreds of processes. If not most of the processes are sleeping, how can CPU respond.

D (TASK_UNINTERRUPTIBLE), uninterruptible sleep state.

Similar to the TASK_INTERRUPTIBLE state, the process is asleep, but at this point the process is uninterruptible. Uninterruptible does not mean that the CPU does not respond to interrupts from 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 cannot kill a sleeping process! So it's easy to understand why the processes seen by the ps command rarely have a TASK_UNINTERRUPTIBLE state, but always have a TASK_INTERRUPTIBLE state.

The significance of the existence of the TASK_UNINTERRUPTIBLE state is that some of the kernel processes cannot be interrupted. If you respond to an asynchronous signal, a process for processing the asynchronous signal is inserted into the program's execution flow (which may only exist in the kernel state or may extend to the user state), and the original process is interrupted (see "linux Asynchronous signal handle Analysis").

When a process operates on some hardware (for example, the 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 interacts with the corresponding physical device), it may be necessary to use TASK_UNINTERRUPTIBLE state to protect the process to prevent the process from interacting with the device and causing the device to fall into an uncontrollable state. (for example, the read system call triggers a DMA of disk-to-user space memory. If the process exits in response to a signal while DMA is in progress, the memory being accessed by DMA may be freed. The TASK_UNINTERRUPTIBLE state in this case is always very short, and it is almost impossible to capture through the ps command.

There are also TASK_UNINTERRUPTIBLE states that are easy to capture in linux systems. After performing the vfork system call, the parent process enters the TASK_UNINTERRUPTIBLE state until the child process calls exit or exec.

The process in the TASK_UNINTERRUPTIBLE state can be obtained through the following code:

# include

Void main () {

If (! vfork ()) sleep

}

Compile and run, and 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. Whether kill or kill-9, the parent process of the TASK_UNINTERRUPTIBLE state is still standing.

T (TASK_STOPPED or TASK_TRACED), paused status or tracking status.

Send a SIGSTOP signal to the process, and it enters the TASK_STOPPED state in response to the signal (unless the process itself is in the TASK_UNINTERRUPTIBLE state and does not respond to the signal). (SIGSTOP, like SIGKILL signals, is very mandatory. User processes are not allowed to reset the corresponding signal handling functions through signal series system calls. )

Send 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 tracking process to operate on it. For example, at the next breakpoint for a tracked process in gdb, the process is in a TASK_TRACED state when it stops at the breakpoint. At other times, the process being tracked is still in the previously mentioned state.

For the process itself, the TASK_STOPPED and TASK_TRACED states are similar, indicating that the process is paused.

The TASK_TRACED state is equivalent to an extra layer of protection on top of the TASK_STOPPED, and the process in the TASK_TRACED state can not be awakened in response to the SIGCONT signal. Only when the debugging process executes PTRACE_CONT, PTRACE_DETACH and other operations through the ptrace system call (specified by the parameters specified by the ptrace system call), or the debugging process exits, the debugged process can restore the TASK_RUNNING state.

Z (TASK_DEAD-EXIT_ZOMBIE), exit state, the process becomes a zombie process.

The process is in a TASK_DEAD state while exiting.

During this exit process, all resources occupied by the process are reclaimed, except for the task_struct structure (and a few resources). So task_struct is the only shell left in the process, so it is called a zombie.

Task_struct is retained because the task_struct holds the exit code of the process, as well as some statistical information. And the parent process is likely to care about this information. For example, in shell, $? Variable holds the exit code of the last exit foreground process, and this exit code is often used as the judgment 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. But using the task_struct structure is more convenient because a lookup relationship from pid to task_struct has been established in the kernel, as well as a parent-child relationship between processes. To release task_struct, you need to establish some new data structures so that the parent process can find the exit information of its child process.

The parent process can wait for the exit of one or some child processes and obtain its exit information through the system calls of the wait series (such as wait4, waitid). Then the system call of the wait series releases the task_struct of the child process by the way.

When a child process exits, the kernel sends a signal to its parent process, informing the parent process to "collect the corpse". This signal defaults to SIGCHLD, but can be set when a child process is created through the clone system call.

You can create an EXIT_ZOMBIE state process with the following code:

# include

Void main () {

If (fork ())

While 1 sleep

}

Compile and run, and 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

As long as the parent process does not exit, the child process in this zombie state will always exist. So if the parent process exits, who will "collect the body" for the child process?

When a process exits, it hosts all of its children to another process (making it a child of another process). Who is the trusteeship for? It could be the next process (if any) in the process group that exits the process, or process 1. So there is a parent process in every process, all the time. Unless it's process 1.

Process 1, the process with pid 1, also known as the init process.

After the linux system starts, the first user-mode process created is the init process. It has two missions:

1. Execute the system initialization script and create a series of processes (they are all 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 "corpse collection" work.

The init process is not paused or killed (this is guaranteed by the kernel). It is in the TASK_INTERRUPTIBLE state while waiting for the child process to exit, and is in the TASK_RUNNING state during the "corpse collection" process.

X (TASK_DEAD-EXIT_DEAD), exit status, the process is about to be destroyed.

And the process may not retain its task_struct during exit. For example, this process is a detach-passed process in a multithreaded program. Or the parent process explicitly ignores the SIGCHLD signal by setting its handler to SIG_IGN. This is the rule of posix, although the exit signal of a child process can be set to something other than SIGCHLD. )

At this point, the process will be placed in the EXIT_DEAD exit state, which means that the following code will immediately completely release the process. So the EXIT_DEAD state is so short that it's almost impossible to capture it with the ps command.

The initial state of the process

Processes are created through fork series system calls (fork, clone, vfork), and the kernel (or kernel module) can also create kernel processes through the kernel_thread function. These functions that create child processes essentially perform the same function-make a copy of the calling process and get the child process. (you can use option parameters to determine whether various resources are shared or private. )

So since the calling process is in the TASK_RUNNING state (otherwise, how can it be called if it is not running? The child process is also in the TASK_RUNNING state by default

In addition, the system call clone and the kernel function kernel_thread also accept the CLONE_STOPPED option, thus setting the initial state of the child process to TASK_STOPPED.

Process state transition

After a process is created, a series of state changes may occur until the process exits. Although there are several process states, the process state changes in only two directions-from TASK_RUNNING state to non-TASK_RUNNING state, or from non-TASK_RUNNING state to TASK_RUNNING state.

That is, if a SIGKILL signal is sent to a process in TASK_INTERRUPTIBLE state, the process will be awakened (into TASK_RUNNING state) and then exited in response to the SIGKILL signal (to TASK_DEAD state). Does not exit directly from the TASK_INTERRUPTIBLE state.

The transition of a process from a non-TASK_RUNNING state to a TASK_RUNNING state is achieved by a wake-up operation performed by another process (or possibly an interrupt handler). The process that performs Wake up sets the state of the awakened process to TASK_RUNNING, and then adds its task_struct structure to the executable queue of some CPU. The awakened process will then have the opportunity to be scheduled for execution.

There are two ways for a process to change from a TASK_RUNNING state to a non-TASK_RUNNING state:

1. Enter TASK_STOPED state or TASK_DEAD state in response to the signal

2. Execute the system call to actively enter the TASK_INTERRUPTIBLE state (such as nanosleep system call) or TASK_DEAD state (such as exit system call), or enter the TASK_INTERRUPTIBLE state or TASK_UNINTERRUPTIBLE state (such as select system call) because the resources needed to execute the system call are not satisfied.

Obviously, both of these situations can only happen if the process is executing on CPU.

This is the end of the content of "what do you think of the Centos process status"? thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.