Linux zombie process and concurrent server programming

Order

The Zombie (zombie) process is simply: when a child process exits, the parent process does not properly handle the sigchild signal it emits, causing the child process to stay in a zombie state to wait for its parent process to corpse, and the child process in this state is a zombie process.

Because concurrent servers often fork many child processes, a server process is required to wait to clean up resources after the child process is terminated. For some processes, especially server processes often generate child processes to process requests when a request arrives. If the parent process does not wait for the child process to end, the child process becomes a zombie process (zombie) and thus consumes system resources. If the parent process waits for the child process to end, it increases the burden on the parent process and affects the concurrency performance of the server process.

Find all Zombie Processes

Ps-a-O Stat,ppid,pid,cmd | Grep-e ' ^[zz] '

Handling Zombie Processesthe simplest way to ignore the SIGCHLD signal is to let the system process

on Linux downgrade signal (SIGCHLD, sig_ign), you can simply set the operation of the SIGCHLD signal to sig_ign ignored. This allows the kernel to transfer the zombie process to the INIT process, eliminating the large number of zombie processes that occupy system resources. (Linux only)

parent Process waitpid Release zombie process

The parent process calls signal before the fork is called to set the SIGCHLD signal handler function. The SIGCHLD processing functions are as follows:

void sig_chld (int signo) {pid_t pid;int Stat;//unix if a signal is generated one or more times during blocking, the signal is usually only submitted once after being unblocked, which means that the UNIX signal is not queued by default. while ((Pid=waitpid ( -1, &stat, Wnohang) > 0) {pintf ("Child%d terminated\n", PID);} return;}

Communication considerations

Signal (Sigpipe, sig_ign);

TCP is a full-duplex channel, can be regarded as two single-channel, TCP connection at each end of the two endpoints are responsible for one. When Close is called on the peer, although the intention is to close the entire two channels,
But this side just receives the fin bag. According to the semantics of the TCP protocol, the peer only shuts down the single channel it is responsible for, and continues to receive data. That is, because of the limitations of the TCP protocol,
An endpoint does not know whether the socket on the peer is called close or shutdown.

Call the Read method on a socket that has received a FIN packet,
If the receive buffer is empty, 0 is returned, which is often said to indicate that the connection is closed. But when the write method is called for the first time, it returns the correct write (send) if the send buffer is not a problem.
But the message sent will cause the RST message to be sent to the end, because the socket on the end has called close, closed completely, neither sent nor received data. So
The second call to the Write method (assuming that the RST is received) generates a sigpipe signal that causes the process to exit.

To avoid a process exit, you can either capture the sigpipe signal or ignore it and set the Sig_ign signal handler function for it:

Signal (Sigpipe, sig_ign);

This way, when the write method is called for the second time, 1 is returned, and errno is set to Sigpipe. The program will know that the peer is closed.