Signal_types.txt

SIGABRT
    A 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.

SIGALRM
    The 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.

SIGBUS
    This 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.

SIGCHLD
    This signal is sent by the kernel to the parent process when one 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.

SIGCLD
    This is a synonym for SIGCHLD

SIGCONT
    When sent to a stopped process, this signal causes the process to
    resume (i.e., to be rescheduled to run at a 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.

SIGEMT
    In 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

SIGFPE
    This signal is generated for certain types of arithmatic errors
    such as divide-by-zero. The suffix FPE is an abbreviation for
    floating-point exception, although this signal can also be
    generated for arithmatic errors. The precise details of when the
    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 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.

SIGHUP
    When 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 which SIGHUP is sent later.
    A second use of SIGHUP is with daemons (e.g. init, httpd, inetd)
    Many daemons are designed to respond to the receipt of SIGHUP by
    reinitializing themselves and rereading their config files. The sys
    admin 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.

SIGILL
    This signal is sent to a process if it tries to execute an illegal
    (i.e. incorrectly formed) machine language instruction.

SIGINFO
    On Linux, this signal name is synonymous with SIGPWR. On BSD sys
    the SIGINFO signal, generated by typing controll T, is used to
    obtain status information about the foreground process group.

SIGINT
    When the user types the terminal interrupt character (usually
    control c) the terminal driver sends the signal to the foreground
    process group. The default action for this signal is to terminate
    the process.

SIGIO
    Using the fcntl() system call, it is possible to arrange for this
    signal to be generated when an I/0 event (e.g., input becoming
    available) occurs on certain types of open file descriptors, such
    those for terminals and sockets.

SIGIOT
    On Linux, this is a synonym for SIGABRT. On some other UNIX imp-
    lementations, this signal indicates an implementation defined
    hardware fault.

SIGKILL
    This is the sure kill signal. It can't be blocked, ignored, or
    caught by the handler, and thus always terminates a process.

SIGLOST
    This signal name exists on Linux, but is unused. On some other
    UNIX implementations, the NFS client sends this signal to the
    to the local processes holding locks if the NSF client fails
    to regain locks held by those processes following the recovery of a
    remote NFS server that crashed. (This feature is not standardized
    in the NFS spec).

SIGPIPE
    This signal, which is derived from the System V, is a synonym
    for SIGIO on Linux.

SIGPROF
    The kernel generates this signal upon the expiration of a profiling
    timer set by a call to setitimer(). A profiling timer is one that
    counts the CPU time used by a process. Unlike a virtual timer
    (see SIGVTALRM), a profiling timer counts CPU time used in both
    user mode and kernel mode.

SIGPWR
    This is the power failure signal. On systems that have 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.

SIGQUIT
    When 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 for a program that is stuck in an infinate
    loop or is otherwise not responding. By typing control \ and then
    loading the resulting core dump with gdb and using backtrace
    command to obtain a stack trace, we can find out which part of the
    program code was executing.

SIGSEGV
    This 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 part of the 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.

SIGSTKFLT
    Documented in signal(7) as "stack fault on coprocessor," this signal
    is defined, but is unused on Linux.

SIGSTOP
    This is the sure stop signal. It can't be blocked, ignored, or
    caught by a handler; thus, it always stops a process.

SIGSYS
    This signal is generated if a process makes a "bad" system call.
    This means that the process executed an instruction that was in-
    terpreted as a system call trap, but the associated system call
    number was not valid.

SIGTERM
    This 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 temp
    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.

SIGTRAP
    This signal is used to implement debugger breakpoints and system
    call tracing, as performed by strace(1). See ptrace(2) manual page
    for further information.

SIGTSTP
    This is the job-control stop signal, sent to stop the foreground
    process group when the user types the suspend character Ctrl+Z

SIGTTIN
    When 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.

SIGTTOU
    This 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.

SIGUNUSED
    As the name implies, this signal is unused. On Linux 2.4 and later,
    this signal name is synonymous with SIGSYS on many architectures,
    although the signal name remains for backward compatibility.

SIGURG
    This signal is sent to a process to indicate the presence of
    out-of-band (also known as urgent) data on a socket.

SIGUSR1
    This 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 implement-
    ations provide a large set of realtime signals that are also
    available for programmer-defined purposes.

SIGVTALRM
    The kernel generates this signal upon expiration of a virtual
    timer set by a call to setitimer(). A virtual timer is one that
    counts the user-mode CPU time used by a process.

SIGWINCH
    In 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(). 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.

SIGXFSZ
    This signal is sent to a process if it attempts (using write() or
    truncate()) to increase the size of the file beyond the process's
    file size resource limit (RLIMIT_FSIZE.)