When a signal is generated, it becomes pending. Normally it
remains pending for just a short period of time and then is
delivered to the process that was signaled. However, if that kind
of signal is currently blocked, it may remain pending
indefinitely—until signals of that kind are unblocked. Once
unblocked, it will be delivered immediately. See Blocking Signals.
When the signal is delivered, whether right away or after a long delay,
the specified action for that signal is taken. For certain
signals, such as SIGKILL and SIGSTOP, the action is fixed,
but for most signals, the program has a choice: ignore the signal,
specify a handler function, or accept the default action for
that kind of signal. The program specifies its choice using functions
such as signal or sigaction (see Signal Actions). We
sometimes say that a handler catches the signal. While the
handler is running, that particular signal is normally blocked.
If the specified action for a kind of signal is to ignore it, then any
such signal which is generated is discarded immediately. This happens
even if the signal is also blocked at the time. A signal discarded in
this way will never be delivered, not even if the program subsequently
specifies a different action for that kind of signal and then unblocks
If a signal arrives which the program has neither handled nor ignored,
its default action takes place. Each kind of signal has its own
default action, documented below (see Standard Signals). For most kinds
of signals, the default action is to terminate the process. For certain
kinds of signals that represent “harmless” events, the default action
is to do nothing.
When a signal terminates a process, its parent process can determine the
cause of termination by examining the termination status code reported
by the wait or waitpid functions. (This is discussed in
more detail in Process Completion.) The information it can get
includes the fact that termination was due to a signal and the kind of
signal involved. If a program you run from a shell is terminated by a
signal, the shell typically prints some kind of error message.
The signals that normally represent program errors have a special
property: when one of these signals terminates the process, it also
writes a core dump file which records the state of the process at
the time of termination. You can examine the core dump with a debugger
to investigate what caused the error.
If you raise a “program error” signal by explicit request, and this
terminates the process, it makes a core dump file just as if the signal
had been due directly to an error.
Published under the terms of the GNU General Public License