• Choose a category
• All
• Classic-Fiction

The signals named KILL and STOP cannot be caught, blocked, or ignored. The KILL signal destroys the receiving process, and STOP suspends its execution until a CONT signal is received. CONT may be caught or ignored, but not blocked.

TSTP is a “soft” version of STOP that might be best described as a request to stop. It’s the signal generated by the terminal driver when you type a on the keyboard. Programs that catch this signal usually clean up their state, then send themselves a STOP signal to complete the stop operation. Alternatively, TSTP may simply be ignored, to prevent the program from being stopped from the keyboard.

The signals KILL, INT, HUP, QUIT, and TERM may all sound as if they mean about the same thing, but their uses are actually quite different. It’s unfortunate that such vague terminology was selected for them. Here’s a decoding guide:

• KILL is unblockable and terminates a process at the OS level. A process can never actually “receive” this signal.

• INT is the signal sent by the terminal driver when you type . It’s a request to terminate the current operation. Simple programs should quit (if they catch the signal) or simply allow themselves to be killed, which is the default if the signal is not caught. Programs that have a command line or input mode should stop what they’re doing, clean up, and wait for user input again.

• TERM is a request to terminate execution completely. It’s expected that the receiving process will clean up its state and exit.

• HUP has two common interpretations. First, it’s understood as a reset request by many daemons. If a daemon is capable of rereading its configuration file and adjusting to changes without restarting, a HUP can generally be used to trigger this behavior.

Second, HUP signals are sometimes generated by the terminal driver in an attempt to “clean up” (i.e., kill) the processes attached to a particular terminal. This can happen, for example, when a terminal session is concluded or when a modem connection is inadvertently dropped (hence the name “hangup”). The details vary by system.

Shells in the C shell family (csh, tcsh, et al.) usually make background processes immune to HUP signals so that they can continue to run after the user logs out. Users of Bourne-ish shells (sh, ksh, bash, etc.) can emulate this behavior with the nohup command.

• QUIT is similar to TERM, except that it defaults to producing a core dump if not caught. A few programs cannibalize this signal and interpret it to mean something else.

The signals USR1 and USR2 have no set meaning. They’re available for programs to use in whatever way they’d like. For example, named interprets these signals as a request to set its debugging level.

4.4 KILL: SEND SIGNALS

As its name implies, the kill command is most often used to terminate a process. kill can send any signal, but by default it sends a TERM. kill can be used by normal users on their own processes or by the superuser on any process. The syntax is

kill [-signal] pid

where signal is the number or symbolic name of the signal to be sent (as shown in Table 4.1) and pid is the process identification number of the target process. On some systems, a pid of -1 broadcasts the signal to all processes except system processes and the current shell.

A kill without a signal number does not guarantee that the process will die because the TERM signal can be caught, blocked, or ignored. The command

kill -9 pid

will “guarantee” that the process will die because signal 9, KILL, cannot be caught. We put quotes around “guarantee” because processes can sometimes become so wedged that even KILL does not affect them (usually because of some degenerate I/O vapor lock such as waiting for a disk that has stopped spinning). Rebooting is usually the only way to get rid of these naughty processes.

4.5 PROCESS STATES

A process is not automatically eligible to receive CPU time just because it exists. There are essentially four execution states that you need to be aware of; they are listed in