SIGNAL(7) | Miscellaneous Information Manual | SIGNAL(7)

# NAME

`signal` —
signal facilities

# DESCRIPTION

A `signal` is a system-level notification delivered to a process. Signals may be generated as the result of process activity, by certain user inputs, by kernel facilities or subsystems, or sent programmatically by other processes or by users. There is a small fixed set of signals, each with a symbolic name and a number. For historical reasons many of the numbers are ``well-known values'', which are in practice the same on all implementations and realistically can never be changed. (Nonetheless, compiled code should always use only the symbolic names.) Many/most signals also have specific semantics, both in how they can be generated and in their effects. Some are special cases in ways that have quite far-reaching consequences.

When a signal is posted (“sent”) to a process, in general any of several things can happen. If the process has elected to ignore the signal, it is discarded and nothing happens. (Some signals may not be ignored, however.) If the process has elected to block the signal temporarily, delivery is postponed until the process later unblocks that signal. Otherwise, the signal is delivered, meaning that whatever the process is doing is interrupted in order to react to the signal. (Note that processes that are waiting in the kernel must unwind what they are doing for signals to be delivered. This can sometimes be expensive. See sigaction(2) for further information.)

If the process has elected to catch the signal, which means that the process has installed a handler to react to the signal in some process-specific way, the kernel arranges for the process's handler logic to be invoked. This is always done in a way that allows the process to resume if desired. (Note, however, that some signals may not be caught.) Otherwise, the default action for the signal is taken. For most signals the default action is a core dump. See the table below. Note that the term delivery is also used for the specific process of arranging for a signal handler to be invoked.

In general, signals are delivered as soon as they are posted. (Some delays may occur due to scheduling.) However, in some cases a process that has been sleeping in the kernel may need to do slow things as part of unwinding its state; this can sometimes lead to human-perceptible delays.

Also, some sleep states within the kernel are uninterruptible meaning that signals posted will have no effect until the state clears. These states are supposed to be short-term only, but sometimes kernel bugs make this not the case and one can end up with unkillable processes. Such processes appear in state "D" in ps(1). In general the only way to get rid of them is to reboot. (However, when the "wchan" reported is "tstile", it means the process is waiting for some other process to release resources; sometimes if one can find and kill that process the situation is recoverable.)

## Signal list

The following signals are defined in NetBSD:

`SIGHUP` | 1 | Hangup
`SIGINT` | 2 | Interrupt
`SIGQUIT` | 3 | Quit
`SIGILL` | 4 | Illegal instruction
`SIGTRAP` | 5 | Trace/BPT trap
`SIGABRT` | 6 | Abort trap
`SIGEMT` | 7 | EMT trap
`SIGFPE` | 8 | Floating point exception
`SIGKILL` | 9 | Killed
`SIGBUS` | 10 | Bus error
`SIGSEGV` | 11 | Segmentation fault
`SIGSYS` | 12 | Bad system call
`SIGPIPE` | 13 | Broken pipe
`SIGALRM` | 14 | Alarm clock
`SIGTERM` | 15 | Terminated
`SIGURG` | 16 | Urgent I/O condition
`SIGSTOP` | 17 | Suspended (signal)
`SIGTSTP` | 18 | Suspended
`SIGCONT` | 19 | Continued
`SIGCHLD` | 20 | Child exited, stopped or continued
`SIGTTIN` | 21 | Stopped (tty input)
`SIGTTOU` | 22 | Stopped (tty output)
`SIGIO` | 23 | I/O possible
`SIGXCPU` | 24 | CPU time limit exceeded
`SIGXFSZ` | 25 | File size limit exceeded
`SIGVTALRM` | 26 | Virtual timer expired
`SIGPROF` | 27 | Profiling timer expired
`SIGWINCH` | 28 | Window size changed
`SIGINFO` | 29 | Information request
`SIGUSR1` | 30 | User defined signal 1
`SIGUSR2` | 31 | User defined signal 2
`SIGPWR` | 32 | Power fail/restart

These are numbered 1 to 32. (There is no signal 0; 0 is a reserved value that can be used as a no-op with some signal operations.)

Detailed descriptions of these signals follow.

`SIGHUP` (Hangup)
  This signal is generated by the tty(4) driver to indicate a hangup condition on a process's controlling terminal: the user has disconnected. Accordingly, the default action is to terminate the process. This signal is also used by many daemons, such as inetd(8), as a cue to reload configuration. The number for `SIGHUP` is 1, which is quite well known.
`SIGINT` (Interrupt)
  This signal is generated by the tty(4) driver when the user presses the interrupt character, normally control-C. The default action is to terminate the process. The number for `SIGINT` is 2.
`SIGQUIT` (Quit)
  This signal is generated by the tty(4) driver when the user presses the quit character, normally control-backspace. The default action is to terminate the process and dump core. The number for `SIGQUIT` is 3.
`SIGILL` (Illegal instruction)
  This signal is generated synchronously by the kernel when the process executes an invalid instruction. The default action is to terminate the process and dump core. Note: the results of executing an illegal instruction when `SIGILL` is blocked or ignored are formally unspecified. The number for `SIGILL` is 4.
`SIGTRAP` (Trace/BPT trap)
  This signal is used when a process is being traced (see ptrace(2)) to indicate that the process has stopped at a breakpoint or after single-stepping. It is normally intercepted by the debugger and not exposed to the debuggee. The default action is to terminate the process and dump core. The number for `SIGTRAP` is 5.
`SIGABRT` (Abort trap)
  This signal is generated when the abort(3) standard library function is called. The default action is to terminate the process and dump core. The number for `SIGABRT` is 6. This number was also formerly used for `SIGIOT`, which is no longer defined, as it was specific to the PDP-11 instruction `iot`.
`SIGEMT` (EMT trap)
  In theory this signal is generated when an instruction needs to be emulated. The default action is to terminate the process and dump core. The number for `SIGEMT` is 7.
`SIGFPE` (Floating point exception)
  This signal is generated when an invalid floating point operation is detected by hardware or by a soft-float library. The default action is to terminate the process and dump core. The number for `SIGFPE` is 8.
`SIGKILL` (Killed)
  This signal cannot be caught or ignored. The (unconditional) action is to terminate the process. It is most often sent by system administrators, but is also generated by the kernel in response to running completely out of memory and swap space. Note that because many processes need to perform cleanup before exiting, it is usually best (as a user or administrator) to not deploy `SIGKILL` until a process has failed to respond to other signals. The number for `SIGKILL` is 9, which is extremely well known.
`SIGBUS` (Bus error)
  This signal is generated synchronously by the kernel when the process performs certain kinds of invalid memory accesses. The most common cause of `SIGBUS` is an unaligned memory access; however, on some architectures it may cover other memory conditions, such as attempts to access memory belonging to the kernel. The default action is to terminate the process and dump core. Note: the results of performing such invalid accesses when `SIGBUS` is blocked or ignored are formally unspecified. The number for `SIGBUS` is 10.
`SIGSEGV` (Segmentation fault)
  This signal is generated synchronously by the kernel when the process attempts to access unmapped memory, or access memory in a manner that the protection settings for that memory region do not permit. On some architectures other assorted permission or protection errors also yield `SIGSEGV`. On NetBSD, passing invalid pointers to system calls will yield failure with `EFAULT` but not also `SIGSEGV`. The default action is to terminate the process and dump core. Note: the results of an invalid memory access when `SIGSEGV` is blocked or ignored are formally unspecified. The number for `SIGSEGV` is 11, which is very well known.
`SIGSYS` (Bad system call)
  This signal is generated by the kernel, in addition to failing with `ENOSYS`, when a system call is made using an invalid system call number. The default action is to terminate the process and dump core. The number for `SIGSYS` is 12.
`SIGPIPE` (Broken pipe)
  This signal is generated by the kernel, in addition to failing with `EPIPE`, when a write(2) call or similar is made on a pipe or socket that has been closed and has no readers. The default action is to terminate the process. The number for `SIGPIPE` is 13.
`SIGALRM` (Alarm clock)
  This signal is generated by the kernel when a real-time timer expires. See alarm(3), setitimer(2), and timer_settime(2). The default action is to terminate the process. The number for `SIGALRM` is 14.
`SIGTERM` (Terminated)
  This signal is the default signal sent by kill(1) and represents a user or administrator request that a program shut down. It is sent to all processes as part of the shutdown(8) procedure. The default action is to terminate the process. The number for `SIGTERM` is 15.
`SIGURG` (Urgent I/O condition)
  This signal is generated when an ``urgent condition'' exists on a socket. In practice this means when tcp(4) out-of-band data has arrived. The default action is to do nothing. The number for `SIGURG` is 16.
`SIGSTOP` (Suspended (signal))
  This signal cannot be caught or ignored. The (unconditional) action is to stop the process. Note that like with `SIGKILL` (and for similar reasons) it is best to not send this signal until a process has failed to respond to `SIGTSTP`. It can also be used by processes to stop themselves after catching `SIGTSTP`. A process that is explicitly stopped will not run again until told to with `SIGCONT`. The number for `SIGSTOP` is 17.
`SIGTSTP` (Suspended)
  This signal is generated by the tty(4) driver when the user presses the stop character, normally control-Z. The default action is to stop the process. The number for `SIGTSTP` is 18.
`SIGCONT` (Continued)
  This signal is generated by the job-control feature of shells to manage processes. It causes the target process to start executing again after previously being stopped. This happens as a magic extra effect `before` the signal is actually delivered. The default action when the signal is delivered is to do nothing (else). The number for `SIGCONT` is 19.
`SIGCHLD` (Child exited, stopped or continued)
  This signal is generated by the kernel when one of a process's immediate children exits and can be waited for using one of the wait(2) family of functions. The default action is to do nothing. As a special case hack, if `SIGCHLD` is ignored (not merely blocked) when a process is created, it is detached from its parent immediately so it need not be waited for. This behavior is a System V historic wart, implemented in NetBSD only for compatibility. It is not portable, not recommended, and should not be used by new code. The number for `SIGCHLD` is 20. This signal was spelled `SIGCLD` in old System V versions and today many systems provide both spellings.
`SIGTTIN` (Stopped (tty input))
  This signal is generated by the tty(4) driver when a process that is not in the foreground of its controlling terminal attempts to read from this terminal. The default action is to stop the process. The number for `SIGTTIN` is 21.
`SIGTTOU` (Stopped (tty output))
  This signal is generated by the tty(4) driver when a process that is not in the foreground of its controlling terminal attempts to write to this terminal, if the terminal is configured accordingly, which is not the default. (See termios(4).) The default action is to stop the process. The number for `SIGTTOU` is 22.
`SIGIO` (I/O possible)
  This signal is sent by the kernel when I/O becomes possible on a file handle opened for asynchronous access with `O_ASYNC`. See open(2) and fcntl(2). The default action is to do nothing. The number for `SIGIO` is 23.
`SIGXCPU` (CPU time limit exceeded)
  This signal is sent by the kernel when the amount of CPU time consumed exceeds the configured limit. See setrlimit(2) and the `ulimit` and `rlimit` builtins of sh(1) and csh(1) respectively. The default action is to terminate the process. The number for `SIGXCPU` is 24.
`SIGXFSZ` (File size limit exceeded)
  This signal is sent by the kernel when a write causes the size of a file to exceed the configured limit. See setrlimit(2) and the `ulimit` and `rlimit` builtins of sh(1) and csh(1) respectively. The default action is to terminate the process. The number for `SIGXFSZ` is 25.
`SIGVTALRM` (Virtual timer expired)
  This signal is generated by the kernel when a virtual-time (process execution time) timer expires. See setitimer(2) and timer_settime(2). The default action is to terminate the process. The number for `SIGVTALRM` is 26.
`SIGPROF` (Profiling timer expired)
  This signal is generated by the kernel when a profiling timer expires. See setitimer(2) and timer_settime(2). The default action is to terminate the process. The number for `SIGPROF` is 27.
`SIGWINCH` (Window size changed)
  This signal is generated by the tty(4) driver when the stored window size of the process's controlling terminal has changed. The default action is to do nothing. The number for `SIGWINCH` is 28.
`SIGINFO` (Information request)
  This signal is generated by the tty(4) driver when the user presses the status request character, normally control-T. The default action is to do nothing. The number for `SIGINFO` is 29.
`SIGUSR1` (User defined signal 1)
  This signal is not generated by the system and is made available for applications to use for their own purposes. Many daemons use it for restart or reload requests of various types. The default action is to terminate the process. The number for `SIGUSR1` is 30.
`SIGUSR2` (User defined signal 2)
  This signal is not generated by the system and is made available for applications to use for their own purposes. The default action is to terminate the process. The number for `SIGUSR2` is 31.
`SIGPWR` (Power fail/restart)
  This signal is notionally sent by the kernel or by a privileged monitor process when an external power failure is detected, and again when power has been restored. Currently NetBSD does not in fact send `SIGPWR`, although it is possible to prepare a custom configuration for powerd(8) that does so. The default action is to do nothing. The number for `SIGPWR` is 32.

## Shell Interface

Signals may be sent with the kill(1) utility, either by number or the symbolic name without the ``SIG'' part. This utility is built into many shells to allow addressing job control jobs.

## Program Interface

In C code signals may be sent using raise(3), kill(2), pthread_kill(3), and some other related functions.

Signals may be caught or ignored using sigaction(2) or the simpler signal(3), and blocked using sigprocmask(2).

# STANDARDS

The `SIGTRAP`, `SIGEMT`, `SIGBUS`, `SIGSYS`, `SIGURG`, `SIGIO`, `SIGXCPU`, `SIGXFSZ`, `SIGVTALRM`, `SIGPROF`, `SIGWINCH`, and `SIGINFO` signals are long-existing Berkeley extensions, available on most BSD-derived systems. The `SIGPWR` signal comes from System V.

The remaining signals conform to IEEE Std 1003.1-1990 (“POSIX.1”).

# HISTORY

`SIGPWR` was introduced in NetBSD 1.4.

May 28, 2018 | NetBSD 9.5