POSIX Signal types

Here I am putting various types of signal types that a process can send,

SIGABRT This signal is generated by calling the abort function. The process terminates abnormally.

SIGALRM This signal is generated when a timer set with the alarm function expires. This signal is also generated when an interval

timer set by the setitimer(2) function expires.

SIGBUS This indicates an implementation-defined hardware fault. Implementations usually generate this signal on certain types of memory faults.

SIGCANCEL This signal is used internally by the Solaris threads library. It is not meant for general use.

SIGCHLD Whenever a process terminates or stops, the SIGCHLD signal is sent to the parent. By default, this signal is ignored, so the parent must catch this signal if it wants to be notified whenever a child's status changes. The normal action in the signal-catching function is to call one of the wait functions to fetch the child's process ID and termination status. Earlier releases of System V had a similar signal named SIGCLD (without the H). The semantics of this signal were different from those of other signals, and asfar back as SVR2, the manual page strongly discouraged its use in new programs. (Strangely enough, this warning disappeared in the SVR3 and SVR4 versions of the manual page.) Applications should use the standard SIGCHLD signal, but be aware that many systems define SIGCLD to be the same as SIGCHLD for backward compatibility. If you maintain software that uses SIGCLD, you need to check your system's manual page to see what semantics it follows.

SIGCONT This job-control signal is sent to a stopped process when it is continued. The default action is to continue a stopped process, but to ignore the signal if the process wasn't stopped. A full-screen editor, for example, might catch this signal and use the signal handler to make a note to redraw the terminal screen.

SIGEMT This indicates an implementation-defined hardware fault.

The name EMT comes from the PDP-11 "emulator trap" instruction. Not all platforms support this signal. On Linux, for example, SIGEMT is supported only for selected architectures, such as SPARC, MIPS, and PA-RISC.

SIGFPE This signals an arithmetic exception, such as divide by 0, floating-point overflow, and so on.

SIGFREEZE This signal is defined only by Solaris. It is used to notify processes that need to take special action before freezing the system state, such as might happen when a system goes into hibernation or suspended mode.

SIGHUP This signal is sent to the controlling process (session leader) associated with a controlling terminal if a disconnect is detected by the terminal interface.

This signal is commonly used to notify daemon processes to

reread their configuration files. The reason SIGHUP is chosen for this is that a daemon should not have a controlling terminal and would normally never receive this signal.

SIGILL This signal indicates that the process has executed an illegal hardware instruction. 4.3BSD generated this signal from the abort function. SIGABRT is now used for this.

SIGINFO This BSD signal is generated by the terminal driver when we type the status key (often Control-T). This signal is sent to all processes in the foreground process group. This signal normally causes status information on processes in the foreground process group to be displayed on the terminal. Linux doesn't provide support for SIGINFO except on the Alpha platform,where it is defined to be the same value as SIGPWR.

SIGINT This signal is generated by the terminal driver when we type the interrupt key (often DELETE or Control-C). This signal is sent to all processes in the foreground process group. This signal is often used to terminate a runaway program, especially when it's generating a lot of unwanted output on the screen.

SIGIO This signal indicates an asynchronous I/O event. We discuss it in Figure 2.1, we labeled the default action for SIGIO as either "terminate" or "ignore." Unfortunately, the default depends on the system. Under System V, SIGIO is identical to SIGPOLL, so its default action is to terminate the process. Under BSD, the default is to ignore the signal. Linux 2.4.22 and Solaris 9 define SIGIO to be the same value as SIGPOLL, so the default behavior is to terminate the process. On FreeBSD 5.2.1 and Mac OS X 10.3, the default is to ignore the signal.

SIGIOT This indicates an implementation-defined hardware fault.

The name IOT comes from the PDP-11 mnemonic for the "input/output TRAP" instruction. Earlier versions of System V generated this signal from the abort function. SIGABRT is now used for this.

On FreeBSD 5.2.1, Linux 2.4.22, Mac OS X 10.3, and Solaris 9, SIGIOT is defined to be the same value as SIGABRT.

SIGKILL This signal is one of the two that can't be caught or ignored. It provides the system administrator with a sure way to kill any process.

SIGLWP This signal is used internally by the Solaris threads library, and is not available for general use.

SIGPIPE If we write to a pipeline but the reader has terminated, SIGPIPE is generated. We describe pipes later. This signal is also generated when a process  writes to a socket of type SOCK_STREAM that is no longer connected.

SIGPOLL This signal can be generated when a specific event occurs on a pollable device. SIGPOLL originated with SVR3, and loosely corresponds to the BSD SIGIO and SIGURG signals. On Linux and Solaris, SIGPOLL is defined to have the same value as SIGIO.

SIGPROF This signal is generated when a profiling interval timer set by the setitimer(2) function expires.

SIGPWR This signal is system dependent. Its main use is on a system that has an uninterruptible power supply (UPS). If power fails, the UPS takes over and the software can usually be notified. Nothing needs to be done at this point, as the system continues running on battery power. But if the battery gets low (if the power is off for an extended period), the software is usually notified again; at this point, it behooves the system to shut everything down within about 1530 seconds. This is when SIGPWR should be sent. Most systems have the process that is notified of the low-battery condition send the SIGPWR signal to the init process, and init handles the shutdown.

Linux 2.4.22 and Solaris 9 have entries in the inittab file for this purpose: powerfail and powerwait (or powerokwait). In Figure 2.1, we labeled the default action for SIGPWR as either "terminate" or "ignore." Unfortunately, the default depends on the system. The default on Linux is to terminate the process. On Solaris, the signal is ignored by default.

SIGQUIT This signal is generated by the terminal driver when we type the terminal quit key (often Control-backslash). This signal is sent to all processes in the foreground process group. This signal not only terminates the foreground process group (as does SIGINT), but also generates a core file.

SIGSEGV This signal indicates that the process has made an invalid memory reference. The name SEGV stands for "segmentation violation."

SIGSTKFLT This signal is defined only by Linux. This signal showed up in the earliest versions of Linux, intended to be used for stack faults taken by the math coprocessor. This signal is not generated by the kernel, but remains for backward compatibility.

SIGSTOP This job-control signal stops a process. It is like the interactive stop signal (SIGTSTP), but SIGSTOP cannot be caught or ignored.

SIGSYS This signals an invalid system call. Somehow, the process executed a machine instruction that the kernel thought was a system call, but the parameter with the instruction that indicates the type of system call was invalid. This might happen if you build a program that uses a new system call and you then try to run the same binary on an older version of the operating system where the system call doesn't exist.

SIGTERM This is the termination signal sent by the kill(1) command by default.

SIGTHAW This signal is defined only by Solaris and is used to notify processes that need to take special action when the system resumes operation after being suspended.

SIGTRAP This indicates an implementation-defined hardware fault.

The signal name comes from the PDP-11 TRAP instruction.

Implementations often use this signal to transfer control to a debugger when a breakpoint instruction is executed.

SIGTSTP This interactive stop signal is generated by the terminal driver when we type the terminal suspend key (often Control-Z). This signal is sent to all processes in the foreground process group.

Unfortunately, the term stop has different meanings. When discussing job control and signals, we talk about stopping and continuing jobs. The terminal driver, however, has historically used the term stop to refer to stopping and starting the terminal output using the Control-S and Control- Q characters. Therefore, the terminal driver calls the character that generates the interactive stop signal the suspend character, not the stop character.

SIGTTIN This signal is generated by the terminal driver when a process in a background process group tries to read from its controlling terminal. As special cases, if either (a) the reading

process is ignoring or blocking this signal or (b) the process group of the reading process is orphaned, then the signal is not generated; instead, the read operation returns an error with errno set to EIO.

SIGTTOU This signal is generated by the terminal driver when a process in a background process group tries to write to its controlling terminal. Unlike the SIGTTIN signal just described, a process has a choice of allowing background writes to the controlling terminal. If background writes are not allowed, then like the SIGTTIN signal, there are two special cases: if either (a) the writing process is ignoring or blocking this signal or (b) the process group of the writing process is orphaned, then the signal is not generated; instead, the write operation returns an error with errno set to EIO. Regardless of whether background writes are allowed, certain terminal operations (other than writing) can also generate the SIGTTOU signal: tcsetattr, tcsendbreak, tcdrain, tcflush, tcflow, and tcsetpgrp.

SIGURG This signal notifies the process that an urgent condition has occurred. This signal is optionally generated when out-of-band data is received on a network connection.

SIGUSR1 This is a user-defined signal, for use in application programs.

SIGUSR2 This is another user-defined signal, similar to SIGUSR1, for use in application programs.

SIGVTALRM This signal is generated when a virtual interval timer set by the setitimer(2) function expires.

SIGWAITING This signal is used internally by the Solaris threads library, and is not available for general use.

SIGWINCH The kernel maintains the size of the window associated with each terminal and pseudo terminal. A process can get and set the window size with the ioctl function, If a process changes the window size from its previous value using the ioctl set-window-size command, the kernel generates the SIGWINCH signal for the foreground process group.

SIGXCPU The Single UNIX Specification supports the concept of resource limits as an XSI extension. If the process exceeds its soft CPU time limit, the SIGXCPU signal is generated. In Figure 2.1, we labeled the default action for SIGXCPU as either "terminate with a core file" or "ignore." Unfortunately, the default depends on the operating system. Linux 2.4.22 and Solaris 9 support a default action of terminate with a core file, whereas FreeBSD 5.2.1 and Mac OS X 10.3 support a default action of ignore. The Single UNIX Specification requires that the default action be to terminate the process abnormally. Whether a core file is generated is left up to the implementation.

SIGXFSZ This signal is generated if the process exceeds its soft file size limit; Just as with SIGXCPU, the default action taken with SIGXFSZ depends on the operating system. On Linux 2.4.22 and Solaris 9, the default is to terminate the process and create a core file. On FreeBSD 5.2.1 and Mac OS X 10.3, the default is to be ignored. The Single UNIX Specification requires that the default action be to terminate the process abnormally. Whether a core file is generated is left up to the implementation.

SIGXRES This signal is defined only by Solaris. This signal is optionally used to notify processes that have exceeded a preconfigured resource value. The Solaris resource control mechanism is a general facility for controlling the use of shared resources among independent application sets.