Listing 7 shows the opposite of Listing 6 — that is, the child dying before the parent. To better illustrate what’s happening, nothing is printed from the process itself. Instead, the interesting information comes from the process listing.
die2 runs in the background using the
& operator, and then a process listing is displayed, showing only the running process and its children. PID 2934 is the parent process, and PID 2935 is the one that is
forked off and terminated immediately. Despite its untimely exit, the child process is still in the process table as a defunct process, otherwise known as a zombie. When the parent dies 60 seconds later, both processes are gone.
When a child process dies, its parent is notified with a signal called
SIGCHLD. The exact mechanics of this are unimportant right now. What is important is that the parent must somehow acknowledge the death of the child. From the time the child dies until the time the parent acknowledges the signal, the child sits in a zombie state. The zombie is not running or consuming CPU cycles; it is merely taking up process table space. When the parent dies, the kernel is finally able to reap the unacknowledged children along with the parent. This means that the only way you can get rid of zombie processes is by killing the parent. The best way to deal with zombies is to make sure they don’t happen in the first place. The code in Listing 8 implements a signal handler to deal with the incoming