Most administrators (and UNIX users) will probably know about the kill command – and will know not to use kill -9 without first trying the kill command by itself. You may also be aware that kill (by itself) sends a SIGTERM signal to the process, and that signal 9 is the SIGKILL signal.
There are many other signals; they are usually available with the kill -l command. OpenBSD returns this output:
# kill -l
1 HUP Hangup 17 STOP Suspended (signal)
2 INT Interrupt 18 TSTP Suspended
3 QUIT Quit 19 CONT Continued
4 ILL Illegal instruction 20 CHLD Child exited
5 TRAP Trace/BPT trap 21 TTIN Stopped (tty input)
6 ABRT Abort trap 22 TTOU Stopped (tty output)
7 EMT EMT trap 23 IO I/O possible
8 FPE Floating point exception 24 XCPU Cputime limit exceeded
9 KILL Killed 25 XFSZ Filesize limit exceeded
10 BUS Bus error 26 VTALRM Virtual timer expired
11 SEGV Segmentation fault 27 PROF Profiling timer expired
12 SYS Bad system call 28 WINCH Window size changes
13 PIPE Broken pipe 29 INFO Information request
14 ALRM Alarm clock 30 USR1 User defined signal 1
15 TERM Terminated 31 USR2 User defined signal 2
16 URG Urgent I/O condition
However, the output is not always so helpful, though it always reports on the available signals. HP-UX reports thusly:
# kill -l
32) The specified trap syntax is not correct.
35) The specified trap syntax is not correct.
36) The specified trap syntax is not correct.
You may also note that higher numbered signals tend to vary more.
There are several signals to note. One not commonly used is SIGCHLD: when you have a zombie process, note the parent of the zombie process and send it a SIGCHLD signal: kill -CHLD ppid . This will, in a proper situation, cause that program to reap its children and cause the zombie to disappear. Whether it actually works or not – you just have to try it.
Another signal not often used is the STOP signal. If there is a unimportant process hogging the processing power of the machine, it can be “stopped” (that is, frozen) and left in its place: kill -STOP pid . Then later, the process can be continued with the command: kill -CONT pid . The process will continue as if it had never stopped.
Another way that the STOP signal can be “sent” is with the shell’s job control mechanism. Using the korn shell, a ^Z (ctrl-z) sent to a process sends the process a SIGSTOP and returns you to the shell. The fg shell command puts the command in the foreground and sends it a SIGCONT. The bg is the same but continues the program in the background. Thus, when a long running process is started in the foreground, and you get tired of waiting – send it a ^z and use bg to put it into the background.
Another way to send signals is by using the pkill command. This is a newer command, apparently introduced in Solaris 7, and now found in HP-UX, OpenBSD, Linux, and probably others. The command pkill is like kill, but allows searching for processes by their attributes (such as userid, terminal, group, state, or even a regular expression) and sends the signal to all that match. Being a newer command, it is best to check the man page for exact syntax.
Yet another signal: EXIT. This is not actually a signal, but is treated by one by some shells (including the Korn Shell). This uses signal 0, and is recognized by the shell’s trap command. Thus, using a trap command with a signal 0 permits the shell to execute things when it exits (such as file cleanup).