Signals are a simple, but important means of interprocess communication. Interprocess communication sounds fancy, but it's really a simple concept: it's the means by which one program sends a message to another program. It's common to think of signals as special messages sent by the but, in fact, any program can signal any other program.
What kinds of messages can you send with a signal? Relatively few, in reality. Signals aren't "arbitrary" messages, like letters; they are a small group of pre-defined messages, each with its own special meaning. System V UNIX supports 16 signals, each of which is assigned a number; BSD-derived UNIX implementations and SVR4 have 32 signals. Table 38.2 lists some of the more commonly used signals. It also lists keyboard characters that send common signals on BSD systems (these can be changed; see article 5.9 ).
While this list isn't definitive, it shows you the types of things signals can do. Many signals, like SIGSEGV , are warning or error messages. You've probably seen the frustrating "segmentation violation" message. That message came when the kernel detected something wrong and sent your program a SIGSEGV signal; in response, your program quit. Others signals, like SIGTSTP , are generated in response to special characters on the keyboard. And a lot of signals just say, "Your time is up, goodbye!"
When a process receives a signal, it can take a number of actions; for example:
You've probably read that the command kill -9 is guaranteed to kill a process. Why? Two special signals in Table 38.2 can't be caught or ignored: the KILL and STOP signals.
Thecommand doesn't kill - it really does nothing more than send signals. As you now know, signals often bring death and destruction - but there's no necessary reason for them to do so.