Earlier, we mentioned that the standard signals are numbered from 1 to 31 on Linux. However, the Linux signal(7) manual page lists more than 31 signal names. The excess names can be accounted for in a variety of ways. Some of the names are simply synonyms for other names, and are defined for source compatibility with other UNIX implementations. Other names are defined but unused. The following list describes the various signals:
SIGABRTA process is sent this signal when it calls the abort() function (Terminating a Process Abnormally: abort()). By default, this signal terminates the process with a core dump. This achieves the intended purpose of the abort() call: to produce a core dump for debugging.
SIGALRMThe kernel generates this signal upon the expiration of a real-time timer set by a call to alarm() or setitimer(). A real-time timer is one that counts according to wall clock time (i.e., the human notion of elapsed time). For further details, see Section 23.1.
SIGBUSThis signal (“bus error”) is generated to indicate certain kinds of memory-access errors. One such error can occur when using memory mappings created with mmap(), if we attempt to access an address that lies beyond the end of the underlying memory-mapped file, as described in Boundary Cases.
SIGCHLDThis signal is sent (by the kernel) to a parent process when one of its children terminates (either by calling exit() or as a result of being killed by a signal). It may also be sent to a process when one of its children is stopped or resumed by a signal. We consider SIGCHLD in detail in Section 26.3.
SIGCLDThis is a synonym for SIGCHLD.
SIGCONTWhen sent to a stopped process, this signal causes the process to resume (i.e., to be rescheduled to run at some later time). When received by a process that is not currently stopped, this signal is ignored by default. A process may catch this signal, so that it carries out some action when it resumes. This signal is covered in more detail in Special Cases for Delivery, Disposition, and Handling and Job Control.
SIGEMTIn UNIX systems generally, this signal is used to indicate an implementation-dependent hardware error. On Linux, this signal is used only in the Sun SPARC implementation. The suffix EMT derives from emulator trap, an assembler mnemonic on the Digital PDP-11.
SIGFPEThis signal is generated for certain types of arithmetic errors, such as divide-by-zero. The suffix FPE is an abbreviation for floating-point exception, although this signal can also be generated for integer arithmetic errors. The precise details of when this signal is generated depend on the hardware architecture and the settings of CPU control registers. For example, on x86-32, integer divide-by-zero always yields a SIGFPE, but the handling of floating-point divide-by-zero depends on whether the FE_DIVBYZERO exception has been enabled. If this exception is enabled (using feenableexcept()), then a floating-point divide-by-zero generates SIGFPE; otherwise, it yields the IEEE-standard result for the operands (a floating-point representation of infinity). See the fenv(3) manual page and <fenv.h> for further information.
SIGHUPWhen a terminal disconnect (hangup) occurs, this signal is sent to the controlling process of the terminal. We describe the concept of a controlling process and the various circumstances in which SIGHUP is sent in Section 34.6. A second use of SIGHUP is with daemons (e.g., init, httpd, and inetd). Many daemons are designed to respond to the receipt of SIGHUP by reinitializing themselves and rereading their configuration files. The system administrator triggers these actions by manually sending SIGHUP to the daemon, either by using an explicit kill command or by executing a program or script that does the same.
SIGILLThis signal is sent to a process if it tries to execute an illegal (i.e., incorrectly formed) machine-language instruction.
SIGINFOOn Linux, this signal name is a synonym for SIGPWR. On BSD systems, the SIGINFO signal, generated by typing Control-T, is used to obtain status information about the foreground process group.
SIGINTWhen the user types the terminal interrupt character (usually Control-C), the terminal driver sends this signal to the foreground process group. The default action for this signal is to terminate the process.
SIGIOUsing the fcntl() system call, it is possible to arrange for this signal to be generated when an I/O event (e.g., input becoming available) occurs on certain types of open file descriptors, such as those for terminals and sockets. This feature is described further in Section 63.3.
SIGIOTOn Linux, this is a synonym for SIGABRT. On some other UNIX implementations, this signal indicates an implementation-defined hardware fault.
SIGKILLThis is the sure kill signal. It can’t be blocked, ignored, or caught by a handler, and thus always terminates a process.
SIGLOSTThis signal name exists on Linux, but is unused. On some other UNIX implementations, the NFS client sends this signal to local processes holding locks if the NSF client fails to regain locks held by the those processes following the recovery of a remote NFS server that crashed. (This feature is not standardized in NFS specifications.)
SIGPIPEThis signal is generated when a process tries to write to a pipe, a FIFO, or a socket for which there is no corresponding reader process. This normally occurs because the reading process has closed its file descriptor for the IPC channel. See Creating and Using Pipes for further details.
SIGPOLLThis signal, which is derived from System V, is a synonym for SIGIO on Linux.
SIGPROFThe kernel generates this signal upon the expiration of a profiling timer set by a call to setitimer() (Interval Timers). A profiling timer is one that counts the CPU time used by a process. Unlike a virtual timer (see SIGVTALRM below), a profiling timer counts CPU time used in both user mode and kernel mode.
SIGPWRThis is the power failure signal. On systems that have an uninterruptible power supply (UPS), it is possible to set up a daemon process that monitors the backup battery level in the event of a power failure. If the battery power is about to run out (after an extended power outage), then the monitoring process sends SIGPWR to the init process, which interprets this signal as a request to shut down the system in a quick and orderly fashion.
SIGQUITWhen the user types the quit character (usually Control-\) on the keyboard, this signal is sent to the foreground process group. By default, this signal terminates a process and causes it to produce a core dump, which can then be used for debugging. Using SIGQUIT in this manner is useful with a program that is stuck in an infinite loop or is otherwise not responding. By typing Control-\ and then loading the resulting core dump with the gdb debugger and using the backtrace command to obtain a stack trace, we can find out which part of the program code was executing. ([Matloff, 2008] describes the use of gdb.)
SIGSEGVThis very popular signal is generated when a program makes an invalid memory reference. A memory reference may be invalid because the referenced page doesn’t exist (e.g., it lies in an unmapped area somewhere between the heap and the stack), the process tried to update a location in read-only memory (e.g., the program text segment or a region of mapped memory marked read-only), or the process tried to access a part of kernel memory while running in user mode (The Core Operating System: The Kernel). In C, these events often result from dereferencing a pointer containing a bad address (e.g., an uninitialized pointer) or passing an invalid argument in a function call. The name of this signal derives from the term segmentation violation.
SIGSTKFLTDocumented in signal(7) as “stack fault on coprocessor,” this signal is defined, but is unused on Linux.
SIGSTOPThis is the sure stop signal. It can’t be blocked, ignored, or caught by a handler; thus, it always stops a process.
SIGSYSThis signal is generated if a process makes a “bad” system call. This means that the process executed an instruction that was interpreted as a system call trap, but the associated system call number was not valid (refer to System Calls).
SIGTERMThis is the standard signal used for terminating a process and is the default signal sent by the kill and killall commands. Users sometimes explicitly send the SIGKILL signal to a process using kill -KILL or kill -9. However, this is generally a mistake. A well-designed application will have a handler for SIGTERM that causes the application to exit gracefully, cleaning up temporary files and releasing other resources beforehand. Killing a process with SIGKILL bypasses the SIGTERM handler. Thus, we should always first attempt to terminate a process using SIGTERM, and reserve SIGKILL as a last resort for killing runaway processes that don’t respond to SIGTERM.
SIGTRAPThis signal is used to implement debugger breakpoints and system call tracing, as performed by strace(1) (Appendix A). See the ptrace(2) manual page for further information.
SIGTSTPThis is the job-control stop signal, sent to stop the foreground process group when the user types the suspend character (usually Control-Z) on the keyboard. Chapter 34 describes process groups (jobs) and job control in detail, as well as details of when and how a program may need to handle this signal. The name of this signal derives from “terminal stop.”
SIGTTINWhen running under a job-control shell, the terminal driver sends this signal to a background process group when it attempts to read() from the terminal. This signal stops a process by default.
SIGTTOUThis signal serves an analogous purpose to SIGTTIN, but for terminal output by background jobs. When running under a job-control shell, if the TOSTOP (terminal output stop) option has been enabled for the terminal (perhaps via the command stty tostop), the terminal driver sends SIGTTOU to a background process group when it attempts to write() to the terminal (see Using Job Control Within the Shell). This signal stops a process by default.
SIGUNUSEDAs the name implies, this signal is unused. On Linux 2.4 and later, this signal name is synonymous with SIGSYS on many architectures. In other words, this signal number is no longer unused on those architectures, although the signal name remains for backward compatibility.
SIGURGThis signal is sent to a process to indicate the presence of out-of-band (also known as urgent) data on a socket (Out-of-Band Data).
SIGUSR1This signal and SIGUSR2 are available for programmer-defined purposes. The kernel never generates these signals for a process. Processes may use these signals to notify one another of events or to synchronize with each other. In early UNIX implementations, these were the only two signals that could be freely used in applications. (In fact, processes can send one another any signal, but this has the potential for confusion if the kernel also generates one of the signals for a process.) Modern UNIX implementations provide a large set of realtime signals that are also available for programmer-defined purposes (Realtime Signals).
SIGUSR2See the description of SIGUSR1.
SIGVTALRMThe kernel generates this signal upon expiration of a virtual timer set by a call to setitimer() (Interval Timers). A virtual timer is one that counts the user-mode CPU time used by a process.
SIGWINCHIn a windowing environment, this signal is sent to the foreground process group when the terminal window size changes (as a consequence either of the user manually resizing it, or of a program resizing it via a call to ioctl(), as described in Terminal Window Size). By installing a handler for this signal, programs such as vi and less can know to redraw their output after a change in window size.
SIGXCPUThis signal is sent to a process when it exceeds its CPU time resource limit (RLIMIT_CPU, described in Details of Specific Resource Limits).
SIGXFSZThis signal is sent to a process if it attempts (using write() or truncate()) to increase the size of a file beyond the process’s file size resource limit (RLIMIT_FSIZE, described in Details of Specific Resource Limits).
Table 20-1 summarizes a range of information about signals on Linux. Note the following points about this table:
The signal number column shows the number assigned to this signal on various hardware architectures. Except where otherwise indicated, signals have the same number on all architectures. Architectural differences in signal numbers are indicated in parentheses, and occur on the Sun SPARC and SPARC64 (S), HP/Compaq/Digital Alpha (A), MIPS (M), and HP PA-RISC (P) architectures. In this column, undef indicates that a symbol is undefined on the indicated architectures.
The SUSv3 column indicates whether the signal is standardized in SUSv3.
The Default column indicates the default action of the signal: term means that the signal terminates the process, core means that the process produces a core dump file and terminates, ignore means that the signal is ignored, stop means that the signal stops the process, and cont means that the signal resumes a stopped process.
Certain of the signals listed previously are not shown in Table 20-1: SIGCLD (synonym for SIGCHLD), SIGINFO (unused), SIGIOT (synonym for SIGABRT), SIGLOST (unused), and SIGUNUSED (synonym for SIGSYS on many architectures).
Table 20-1. Linux signals
Name | Signal number | Description | SUSv3 | Default |
|---|---|---|---|---|
| 6 | Abort process | • | core |
| 14 | Real-time timer expired | • | term |
| 7 (SAMP=10) | Memory access error | • | core |
| 17 (SA=20, MP=18) | Child terminated or stopped | • | ignore |
| 18 (SA=19, M=25, P=26) | Continue if stopped | • | cont |
| undef (SAMP=7) | Hardware fault | term | |
| 8 | Arithmetic exception | • | core |
| 1 | Hangup | • | term |
| 4 | Illegal instruction | • | core |
| 2 | Terminal interrupt | • | term |
| 29 (SA=23, MP=22) | I/O possible | • | term |
| 9 | Sure kill | • | term |
| 13 | Broken pipe | • | term |
| 27 (M=29, P=21) | Profiling timer expired | • | term |
| 30 (SA=29, MP=19) | Power about to fail | term | |
| 3 | Terminal quit | • | core |
| 11 | Invalid memory reference | • | core |
| 16 (SAM=undef, P=36) | Stack fault on coprocessor | term | |
| 19 (SA=17, M=23, P=24) | Sure stop | • | stop |
| 31 (SAMP=12) | Invalid system call | • | core |
| 15 | Terminate process | • | term |
| 5 | Trace/breakpoint trap | • | core |
| 20 (SA=18, M=24, P=25) | Terminal stop | • | stop |
| 21 (M=26, P=27) | Terminal read from BG | • | stop |
| 22 (M=27, P=28) | Terminal write from BG | • | stop |
| 23 (SA=16, M=21, P=29) | Urgent data on socket | • | ignore |
| 10 (SA=30, MP=16) | User-defined signal 1 | • | term |
| 12 (SA=31, MP=17) | User-defined signal 2 | • | term |
| 26 (M=28, P=20) | Virtual timer expired | • | term |
| 28 (M=20, P=23) | Terminal window size change | ignore | |
| 24 (M=30, P=33) | CPU time limit exceeded | • | core |
| 25 (M=31, P=34) | File size limit exceeded | • | core |
Note the following points regarding the default behavior shown for certain signals in Table 20-1:
On Linux 2.2, the default action for the signals SIGXCPU, SIGXFSZ, SIGSYS, and SIGBUS is to terminate the process without producing a core dump. From kernel 2.4 onward, Linux conforms to the requirements of SUSv3, with these signals causing termination with a core dump. On several other UNIX implementations, SIGXCPU and SIGXFSZ are treated in the same way as on Linux 2.2.
SIGPWR is typically ignored by default on those other UNIX implementations where it appears.
SIGIO is ignored by default on several UNIX implementations (particularly BSD derivatives).
Although not specified by any standards, SIGEMT appears on most UNIX implementations. However, this signal typically results in termination with a core dump on other implementations.
In SUSv1, the default action for SIGURG was specified as process termination, and this is the default in some older UNIX implementations. SUSv2 adopted the current specification (ignore).