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 |
Hangup |
SIGINT |
Interrupt |
SIGQUIT |
Quit |
SIGILL |
Illegal instruction |
SIGTRAP |
Trace/BPT trap |
SIGABRT |
Abort trap |
SIGEMT |
EMT trap |
SIGFPE |
Floating point
exception |
SIGKILL |
Killed |
SIGBUS |
Bus error |
SIGSEGV |
Segmentation fault |
SIGSYS |
Bad system call |
SIGPIPE |
Broken pipe |
SIGALRM |
Alarm clock |
SIGTERM |
Terminated |
SIGURG |
Urgent I/O condition |
SIGSTOP |
Suspended (signal) |
SIGTSTP |
Suspended |
SIGCONT |
Continued |
SIGCHLD |
Child exited |
SIGTTIN |
Stopped (tty input) |
SIGTTOU |
Stopped (tty output) |
SIGIO |
I/O possible |
SIGXCPU |
CPU time limit
exceeded |
SIGXFSZ |
File size limit
exceeded |
SIGVTALRM |
Virtual timer expired |
SIGPROF |
Profiling timer
expired |
SIGWINCH |
Window size changed |
SIGINFO |
Information request |
SIGUSR1 |
User defined signal 1 |
SIGUSR2 |
User defined signal 2 |
SIGPWR |
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 driver
tty(4) 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 driver
tty(4) 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 driver
tty(4) 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.
-
-
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 driver
tty(4) 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)
- 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 driver
tty(4) 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 driver
tty(4) 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 driver
tty(4) 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 driver
tty(4) 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.