Linux kernel source code learning: Zombie processes, Linux kernel source code botnets

Linux kernel source code learning: Zombie processes, Linux kernel source code botnets

Orphan and botnets

After a normal sub-process fork parent process, the two establish a parent-child relationship.

When the child process ends, it notifies the parent process, clears the memory occupied by the child process, and leaves its exit information (exit code) in the kernel. If the child process runs smoothly, it is 0; if an error or exception occurs, it is an integer greater than 0 ). In this information, it explains why the process exits. The parent process is responsible for using the wait system to call the child process when it is known that the child process is terminated. This wait function can retrieve the exit information of the sub-process from the kernel and clear the space occupied by this information in the kernel. This is normal.

If the parent process ends earlier than the child process, the child process becomes an orphan (orphand) process. The orphan process is passed to the init process, and the init process becomes the parent process of the process. The init process is responsible for calling the wait function when the child process ends.

Of course, a bad program may also cause the exit information of the child process to be stuck in the kernel (the parent process does not call the wait function for the child process). In this case, sub-processes become zombie processes. When a large number of zombie processes accumulate, the memory space will be occupied.

What is the significance of a botnet status?

The botnet status is an inevitable state of processes in the system, that is, when the system exits and sends a message to its parent process waiting for recycling, under normal circumstances, the parent process can be processed within a short period of time, and the zombie state of the zombie process will last for a long time.

The purpose of setting botnets for a process is to maintain the information of the child process so that the parent process can obtain the information at a later time. This information includes the sub-process ID, termination status, and resource utilization information (CPU time, memory usage, and so on ).

What is generated by a zombie process in the memory?

In the memory, the process descriptor is used to describe the data structure of the process, that is, the task_struct instance of the process.

Why does the child botnets of the parent process disappear after the parent process dies??

If a process is terminated and a child process is in the botnet state, the parent process ID of all its zombie child processes will be reset to 1 (init process ). The init processes that inherit these sub-processes will clear them (the init process will wait them to remove zombie states ). Because the zombie process becomes an orphan process after the parent process dies, the int process is responsible for collecting the dead of these orphan processes. It should be executed at intervals. This is also a remedy for botnets.

How can we prevent zombie processes from being generated?

1) find a solution to the wait sub-process

1. wait sub-process in the parent process after fork

2. Find a way to capture the messages sent by the kernel after the sub-process is completed, and wait is used in the message processing function.

Void sig_chld (int signo ){

Pid_t pid;

Int stat;

Pid = wait (& stat );

Printf ("child % d exit \ n", pid );

Return;

}

Int main (){

Signal (SIGCHLD, & sig_chld );

}

The above process first registers a signal processing function (sig_chld) for the SIGCHLD signal in the main function, and then when the sub-process exits, when the kernel submits a SIGCHLD, it will be captured by the main process and enter the signal processing function sig_chld, and then call wait in sig_chld to clear the exited sub-process. In this way, the child process that exits will not become a zombie process.

The following blog mentions that this wait method has a defect. The correct method should be to call waitpid. What is the difference between the two? I don't know. Http://www.cnblogs.com/yuxingfirst/p/3165407.html

2) Call fork twice. The following program implements this.

The idea is very simple. First, fork's original process gets the son process, then fork's son process's child process, and then let the son process die. In this way, because the son process exits first, sun Tzu process was taken over by init, in fact with the initial parent process out of the relationship, will not be frozen (at this time Sun Tzu process parent process is equivalent to the init process) http://yejun8500.blog.163.com/blog/static/463360020104555814706/

 

 

What is the basis for learning the Linux kernel source code?

C language + operating system knowledge (required)

How does a Linux zombie process appear?

Of course, it will become a zombie process. Your C and D sub-processes will end first than the parent process,
In the fork ()/execve () process, assume that the parent process still exists at the end of the Child process, and the parent process fork () has not installed the SIGCHLD signal processing function to call waitpid () when the sub-process ends and the signal is not explicitly ignored, the sub-process becomes a zombie and cannot end normally. In this case, even the root identity kill-9 cannot kill the zombie process. The remedy is to kill the parent process of the zombie process (the parent process of the zombie process must exist). The zombie process becomes an "orphan process" and passes the process init to process 1, init is always responsible for cleaning up zombie processes.
Zombie process avoidance:
(1) The parent process waits for the child process to end through functions such as wait and waitpid, which causes the parent process to stop.
(2) If the parent process is very busy, you can use the signal function to install handler for SIGCHLD, because after the child process ends, the parent process will receive this signal and can call wait in the handler for recycling.
(3) If the parent process does not care about when the child process ends, you can use SIGCHLD (SIG_IGN) to notify the kernel that you are not interested in the end of the Child process. After the child process ends,
The kernel recycles and does not send signals to the parent process.
(4) There are some other skills: fork two times, the parent process fork a sub-process, and then continue to work, the sub-process fork a sun process and exit, then the sun process is taken over by init, after Sun's process ends,
Init will be recycled. However, the sub-process must be recycled by itself.