signal(5) signal(5)
NAME
signal - base signals
SYNOPSIS
#include <signal.h>
DESCRIPTION
A signal is an asynchronous notification of an event. A signal is
said to be generated for (or sent to) a process when the event
associated with that signal first occurs. Examples of such events
include hardware faults, timer expiration and terminal activity, as
well as the invocation of the kill or sigsend system calls. In some
circumstances, the same event generates signals for multiple
processes. A process may request a detailed notification of the
source of the signal and the reason why it was generated [see
siginfo(5)].
Each process may specify a system action to be taken in response to
each signal sent to it, called the signal's disposition. The set of
system signal actions for a process is initialized from that of its
parent. Once an action is installed for a specific signal, it
usually remains installed until another disposition is explicitly
requested by a call to either sigaction, signal or sigset, or until
the process execs [see sigaction(2) and signal(2)]. When a process
execs, all signals whose disposition has been set to catch the signal
will be set to SIG_DFL. Alternatively, a process may request that
the system automatically reset the disposition of a signal to SIG_DFL
after it has been caught [see sigaction(2) and signal(2)].
A signal is said to be delivered to a process when the appropriate
action for the process and signal is taken. During the time between
the generation of a signal and its delivery, the signal is said to be
pending [see sigpending(2)]. Ordinarily, this interval cannot be
detected by an application. However, a signal can be blocked from
delivery to a process [see signal(2) and sigprocmask(2)]. If the
action associated with a blocked signal is anything other than to
ignore the signal, and if that signal is generated for the process,
the signal remains pending until either it is unblocked or the
signal's disposition requests that the signal be ignored. If the
signal disposition of a blocked signal requests that the signal be
ignored, and if that signal is generated for the process, the signal
is discarded immediately upon generation.
Each process has a signal mask that defines the set of signals
currently blocked from delivery to it [see sigprocmask(2)]. The
signal mask for a process is initialized from that of its parent.
The determination of which action is taken in response to a signal is
made at the time the signal is delivered, allowing for any changes
since the time of generation. This determination is independent of
the means by which the signal was originally generated.
7/91 Page 1
signal(5) signal(5)
The signals currently defined in <signal.h> are as follows:
Name Value Default Event
_________________________________________________________________________
SIGHUP 1 Exit Hangup [see termio(7)]
SIGINT 2 Exit Interrupt [see termio(7)]
SIGQUIT 3 Core Quit [see termio(7)]
SIGILL 4 Core Illegal Instruction
SIGTRAP 5 Core Trace/Breakpoint Trap
SIGABRT 6 Core Abort
SIGEMT 7 Core Emulation Trap
SIGFPE 8 Core Arithmetic Exception
SIGKILL 9 Exit Killed
SIGBUS 10 Core Bus Error
SIGSEGV 11 Core Segmentation Fault
SIGSYS 12 Core Bad System Call
SIGPIPE 13 Exit Broken Pipe
SIGALRM 14 Exit Alarm Clock
SIGTERM 15 Exit Terminated
SIGUSR1 16 Exit User Signal 1
SIGUSR2 17 Exit User Signal 2
SIGCHLD 18 Ignore Child Status Changed
SIGPWR 19 Ignore Power Fail/Restart
SIGWINCH 20 Ignore Window Size Change
SIGURG 33 Ignore Urgent Socket Condition
SIGPOLL 22 Exit Pollable Event [see streamio(7)]
SIGSTOP 23 Stop Stopped (signal)
SIGTSTP 24 Stop Stopped (user) [see termio(7)]
SIGCONT 25 Ignore Continued
SIGTTIN 26 Stop Stopped (tty input) [see termio(7)]
SIGTTOU 27 Stop Stopped (tty output) [see termio(7)]
SIGVTALRM 37 Exit Virtual Timer Expired
SIGPROF 38 Exit Profiling Timer Expired
SIGXCPU 35 Core CPU time limit exceeded [see getrlimit(2)]
SIGXFSZ 36 Core File size limit exceeded [see getrlimit(2)]
SIGIO 34 Core Socket I/O possible
Using the signal, sigset or sigaction system call, a process may
specify one of three dispositions for a signal: take the default
action for the signal, ignore the signal, or catch the signal.
Default Action: SIG_DFL
A disposition of SIG_DFL specifies the default action. The default
action for each signal is listed in the table above and is selected
from the following:
Exit When it gets the signal, the receiving process is to be
terminated with all the consequences outlined in exit(2).
Core When it gets the signal, the receiving process is to be
terminated with all the consequences outlined in exit(2). In
addition, a ``core image'' of the process is constructed in
Page 2 7/91
signal(5) signal(5)
the current working directory.
Stop When it gets the signal, the receiving process is to stop.
Ignore When it gets the signal, the receiving process is to ignore
it. This is identical to setting the disposition to SIG_IGN.
Ignore Signal: SIG_IGN
A disposition of SIG_IGN specifies that the signal is to be ignored.
Catch Signal: function address
A disposition that is a function address specifies that, when it gets
the signal, the receiving process is to execute the signal handler at
the specified address. Normally, the signal handler is passed the
signal number as its only argument; if the disposition was set with
the sigaction function however, additional arguments may be requested
[see sigaction(2)]. When the signal handler returns, the receiving
process resumes execution at the point it was interrupted, unless the
signal handler makes other arrangements. If an invalid function
address is specified, results are undefined.
If the disposition has been set with the sigset or sigaction
function, the signal is automatically blocked by the system while the
signal catcher is executing. If a longjmp [see setjmp(3C)] is used
to leave the signal catcher, then the signal must be explicitly
unblocked by the user [see signal(2) and sigprocmask(2)].
If execution of the signal handler interrupts a blocked system call,
the handler is executed and the interrupted system call returns a -1
to the calling process with errno set to EINTR. However, if the
SA_RESTART flag is set the system call will be transparently
restarted.
NOTES
The dispositions of the SIGKILL and SIGSTOP signals cannot be altered
from their default values. The system generates an error if this is
attempted.
The SIGKILL and SIGSTOP signals cannot be blocked. The system
silently enforces this restriction.
Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU
signal, regardless of its disposition, any pending SIGCONT signal are
discarded.
Whenever a process receives a SIGCONT signal, regardless of its
disposition, any pending SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU
signals is discarded. In addition, if the process was stopped, it is
continued.
7/91 Page 3
signal(5) signal(5)
SIGPOLL is issued when a file descriptor corresponding to a STREAMS
[see intro(2)] file has a ``selectable'' event pending. A process
must specifically request that this signal be sent using the I_SETSIG
ioctl call. Otherwise, the process will never receive SIGPOLL.
If the disposition of the SIGCHLD signal has been set with signal or
sigset, or with sigaction and the SA_NOCLDSTOP flag has been
specified, it will only be sent to the calling process when its
children exit; otherwise, it will also be sent when the calling
process's children are stopped or continued due to job control.
The name SIGCLD is also defined in this header file and identifies
the same signal as SIGCHLD. SIGCLD is provided for backward
compatibility, new applications should use SIGCHLD.
The disposition of signals that are inherited as SIG_IGN should not
be changed.
SEE ALSO
exit(2), getrlimit(2), intro(2), kill(2), pause(2), sigaction(2),
sigaltstack(2), signal(2), sigprocmask(2), sigsend(2), sigsuspend(2),
wait(2), sigsetops(3C), siginfo(5), ucontext(5)
Page 4 7/91