UNIX System Administration Handbook - Evi Nemeth [39]
This scheme works fine if parents outlive their children and are conscientious about calling wait so that dead processes can be disposed of. If the parent dies first, however, the kernel recognizes that no wait will be forthcoming and adjusts the process to make the orphan a child of init. init is supposed to accept these orphaned processes and perform the wait needed to get rid of them when they die.
In the past, init occasionally did not do its job properly and zombies—processes that are no longer actually running but are still listed by the kernel—were left around. We have not seen this behavior recently, however.
4.3 SIGNALS
Signals are process-level interrupt requests. About thirty different kinds are defined, and they’re used in a variety of ways:
• They can be sent among processes as a means of communication.
• They can be sent by the terminal driver to kill, interrupt, or suspend processes when special keys such as • They can be sent by the administrator (with kill) to achieve various results. • They can be sent by the kernel when a process commits an infraction such as division by zero. When a signal is received, one of two things can happen. If the receiving process has designated a handler routine for that particular signal, the handler is called with information about the context in which the signal was delivered. Otherwise, the kernel takes some default action on behalf of the process. The default action varies from signal to signal. Many signals terminate the process; some also generate a core dump. A core dump is a memory image of a process that can be used for debugging. Specifying a handler routine for a signal within a program is referred to as “catching” the signal. When the handler completes, execution restarts from the point at which the signal was received. To prevent signals from arriving, programs can request that they be either ignored or blocked. A signal that is ignored is simply discarded and has no effect on the process. A blocked signal is queued for delivery, but the kernel doesn’t require the process to act on it until the signal has been explicitly unblocked. The handler for a newly unblocked signal is called only once, even if the signal was received several times while reception was blocked. Table 4.1 lists the signals that all administrators should know. The uppercase convention for signal names derives from C language tradition. You might also sometimes see signal names written with a SIG prefix (e.g., SIGHUP) for similar reasons. Table 4.1 UNIX signals that every administrator should know a. Varies among systems. See /usr/include/signal.h or man signal for more specific information. There are other signals not shown in Table 4.1, most of which are used to report obscure errors such as “illegal instruction.” The default handling for signals like that is to terminate with a core dump. Catching and blocking are generally allowed because some programs may be smart enough to try to clean up whatever problem caused the error before continuing. The BUS and SEGV signals are also error signals. We’ve included them in the table because they’re so common: 99% of the time that a program crashes, it’s ultimately one of these two signals that finally brings it down. By themselves, the signals are of no specific diagnostic value. Both of them indicate an attempt to use or access memory improperly. Most terminal emulators will send a WINCH signal when their configuration parameters (such as the number of lines in the virtual terminal) change. This convention allows emulator-savvy programs (text editors, mostly) to reconfigure themselves automatically in response to changes. If you can’t get windows to resize properly, make sure that WINCH is being generated and propagated