signal(5)signal(5)NAME
signal: signal.h - description of signals
SYNOPSISDESCRIPTION
The header defines the following symbolic constants, each of which
expands to a distinct constant expression of the type:
whose value matches no declarable function.
Request for default signal handling.
Return value from
in case of error.
Request that signal be held.
Request that signal be ignored.
The following data types are defined through
sig_atomic_t Integral type of an object that can be accessed
as an atomic entity, even in the presence of
asynchronous interrupts
sigset_t Integral or structure type of an object used to
represent sets of signals.
pid_t As described in
This header also declares the constants that are used to refer to the
signals that occur in the system. Signals defined here begin with the
letters Each of the signals have distinct positive integral values. The
value 0 is reserved for use as the null signal (see kill(2)). Addi‐
tional implementation-dependent signals may occur in the system.
HP-UX supports multiple signal interfaces (see sigaction(2), signal(2),
and sigset(3C)) that allow a process to specify the action taken upon
receipt of a signal.
The following signals are supported on all implementations. The
default actions A (Abort), C (Continue), I (Ignore), S (Stop) and T
(Abnormal Termination) are explained after the table.
Default
Signal Action Description
SIGABRT A Process abort signal.
Same as SIGIOT.
SIGALRM T Alarm clock.
SIGBUS A Access to undefined portion of a memory object.
SIGCHLD I Child process terminated or stopped.
Same as SIGCLD.
SIGCLD I Same as SIGCHLD (also see WARNINGS below).
SIGCONT C Continue executing, if stopped.
SIGEMT A Software generated signal.
SIGFPE A Erroneous arithmetic operation.
SIGHUP T Hangup.
SIGILL A Illegal instruction.
SIGIO I Asynchronous I/O signal; see select(2).
Same as SIGPOLL.
SIGIOT A Process abort signal. Same as SIGABRT.
SIGINT T Terminal interrupt signal.
SIGKILL T Kill (cannot be caught or ignored).
SIGLOST A File lock lost (NFS file locking).
SIGPIPE T Write on a pipe with no one to read it.
SIGPOLL T Pollable event.
SIGQUIT A Terminal quit signal.
SIGSEGV A Invalid memory reference.
SIGSTOP S Stop executing (cannot be caught or ignored).
SIGTERM T Termination signal.
SIGTSTP S Terminal stop signal.
SIGTTIN S Background process attempting read.
SIGTTOU S Background process attempting write.
SIGUSR1 T User-defined signal 1.
SIGUSR2 T User-defined signal 2.
SIGPOLL T Pollable event.
SIGPROF T Profiling timer expired.
SIGPWR I Power fail (see WARNINGS below).
SIGSYS A Bad system call.
SIGTRAP A Trace/breakpoint trap.
SIGURG I High bandwidth data is available at a socket.
SIGVTALRM T Virtual timer expired.
SIGWINCH I Window size change; see termio(7).
SIGXCPU A CPU time limit exceeded.
SIGXFSZ A File size limit exceeded.
SIGRTMIN T First realtime signal.
SIGRTMAX T Last realtime signal.
The macros and evaluate to integral expressions, and specify a range
that includes at least signal numbers that are reserved for application
use and for which the realtime signal extensions are supported (see
sigaction(2)).
The default actions are as follows:
A Abnormal termination of the process. Additionally, for
some signals having this default action, If the fol‐
lowing conditions are met, generate a core image file
(see core(4)) in the current working directory of the
receiving process:
· The effective user ID and the real user ID of the
receiving process are equal.
· The effective group ID and the real group ID of the
receiving process are equal.
· A regular file named does not exist and can be cre‐
ated, or exists and is writable.
If the file is created, it has the following proper‐
ties:
· The file mode is 0600, modified by the file cre‐
ation mode mask (see umask(2)).
· The file user ID is equal to the effective user ID
of the receiving process.
· The file group ID is equal to the effective group
ID of the receiving process.
C Continue the process, if it is stopped; otherwise
ignore the signal.
I Ignore the signal.
S Stop the process. While a process is stopped, any
additional signals sent to the process are suspended
until the process is restarted (except which is pro‐
cessed immediately). However, when the process is
restarted, pending signals are processed. When a
process that is in an orphaned process group (see
glossary(9)) receives a or signal, the process is not
stopped because a process in an orphaned process group
is not allowed to stop. Instead, a signal is sent to
the process, and the or is discarded.
T Abnormal termination of the process. The process is
terminated with all the consequences of except that
the status made available to and indicates abnormal
termination by the specified signal. See exit(2),
wait(2), waitpid(2).
The header provides a declaration of struct including at least the fol‐
lowing members:
void (*sa_handler)(int) what to do on
receipt of signal
sigset_t sa_mask set of signals to be
blocked during exe‐
cution of the signal
handling function
int sa_flags special flags
void (*) sa_sigaction pointer to signal
(int, siginfo_t *, void *) handler function
or one of the macros
SIG_IGN or SIG_DFL
The storage occupied by sa_handler and sa_sigaction may overlap, and a
portable program must not use both simultaneously.
The following are declared as constants:
Do not generate when children stop.
The resulting set is the union of the current set and the
signal set pointed to by the argument
set.
The resulting set is the intersection of the current set
and the complement of the signal set
pointed to by the argument set.
The resulting set is the signal set pointed to by the argument
set. Causes signal delivery to occur
on an alternate stack.
Causes signal dispositions to be set to
on entry to signal handlers.
Causes certain functions to become restartable.
Causes extra information to be passed to signal handlers at the
time of receipt of a signal.
Causes implementations not to create zombie processes on child
death.
Causes signal not to be automatically blocked on entry to
signal handler.
Process is executing on an alternate signal stack.
Alternate signal stack is disabled.
Minimum stack size for a signal handler.
Default size in bytes for the alternate signal stack.
The structure is defined through as described in
The structure is defined through as described in
The header defines the type as a structure that includes at least the
following members:
void *ss_sp stack base or pointer
size_t ss_size stack size
int ss_flags flags
The header defines the structure that includes at least the following
members:
int ss_onstack non-zero when signal stack is in use
void *ss_sp signal stack pointer
The header defines the structure that includes at least the following
members:
int sigev_notify Notification type
int sigev_signo Signal number
union sigval sigev_value Signal value.
The sigev_notify member specifies the notification mechanism to use
when an asynchronous event occurs. The following values are defined for
the sigev_notify member:
No asynchronous notification will be delivered when the
event of interest occurs.
The signal specified in sigev_signo will be generated for the
process when the event of interest
occurs. If is set for that signal num‐
ber, then the signal will be queued to
the process, and the value specified in
sigev_value will be the sigev_value
component of the generated signal. If
is not set for that signal number, it
is unspecified whether the signal is
queued, and what value, if any, is
sent.
The sigev_signo member specifies the signal to be generated. The
sigev_value member is the application-defined value to be passed to the
signal-catching function at the time of the signal delivery or to be
returned at signal acceptance as the si_value member of the siginfo_t
structure.
The header defines as a union that includes at least the following mem‐
bers:
int sival_int Integer signal value
void * sival_ptr Pointer signal value.
The header defines the type as a structure that includes at least the
following members:
int si_signo signal number
int si_errno if non-zero, an value associ‐
ated with this signal, as
defined in
int si_code signal code
union sigval si_value signal value
id_t si_pid sending process ID
uid_t si_uid real user ID of sending process
void *si_addr address of faulting instruction
int si_status exit value or signal
long si_band band event for SIGPOLL
The si_code member contains a code identifying the cause of the signal.
The following values are defined for si_code:
The signal was sent by The si_code may be set to also if the
signal was sent by (see or similar
functions that are provided as imple‐
mentation extensions of
The signal was sent by
The signal was generated by the expiration of
a timer set by
The signal was generated by the completion of
an asynchronous I/O request.
The signal was generated by the arrival of
a message on an empty message queue.
If the signal was not generated by one of the functions or events
listed above (such as and other functions), the si_code will be set to
an implementation-defined value (see the Code column below) that is not
equal to any of the values defined above for si_code.
If si_code is one of or then si_value will contain the application-
specified signal value. Otherwise, the contents of si_value are unde‐
fined.
The macros specified in the Code column of the following table are
defined for use as values of si_code that are signal-specific reasons
why the signal was generated.
Signal Code Reason
SIGILL ILL_ILLOPC illegal opcode
ILL_ILLOPN illegal operand
ILL_ILLADR illegal addressing mode
ILL_ILLTRP illegal trap
ILL_PRVOPC privileged opcode
ILL_PRVREG privileged register
ILL_COPROC coprocessor error
ILL_BADSTK internal stack error
SIGFPE FPE_INTDIV integer divide by zero
FPE_INTOVF integer overflow
FPE_FLTDIV floating point divide by zero
FPE_FLTOVF floating point overflow
FPE_FLTUND floating point underflow
FPE_FLTRES floating point inexact result
FPE_FLTINV invalid floating point operation
FPE_FLTSUB subscript out of range
SIGSEGV SEGV_MAPERR address not mapped to object
SEGV_ACCERR invalid permissions for mapped object
SIGBUS BUS_ADRALN invalid address alignment
BUS_ADRERR non-existent physical address
BUS_OBJERR object specific hardware error
SIGTRAP TRAP_BRKPT process breakpoint
TRAP_TRACE process trace trap
SIGCHLD CLD_EXITED child has exited
CLD_KILLED child has terminated abnormally and
did not create a core file
CLD_DUMPED child has terminated and created a core file
CLD_KILLED child was killed
CLD_DUMPED child has terminated abnormally
CLD_TRAPPED traced child has trapped
CLD_STOPPED child has stopped
CLD_CONTINUED stopped child has continued
SIGPOLL POLL_IN data input available
POLL_OUT output buffers available
POLL_MSG input message available
POLL_ERR I/O error
POLL_PRI high priority input available
POLL_HUP device disconnected
Implementations may support additional si_code values not included in
this list, may generate values included in this list under circum‐
stances other than those described in this list, and may contain exten‐
sions or limitations that prevent some values from being generated.
Implementations will not generate a different value from the ones
described in this list for circumstances described in this list.
In addition, the following signal-specific information will be avail‐
able:
Signal Member Value
SIGILL void * si_addr address of faulting instruction
SIGFP
SIGSEGV void * si_addr address of faulting memory reference
SIGBUS
SIGCHLD pid_t si_pid child process ID
int si_status exit value or signal
uid_t si_uid real user ID of the process that
sent the signal
SIGPOLL long si_band band event for or
For some implementations, the value of si_addr may be inaccurate.
The following are declared as functions and may also be defined as
macros:
APPLICATION USAGE
Upon receipt of the signal, if is used to set the action to the address
of a signal handler, the action for the signal caught is reset to
(except and Then, the signal-catching function is executed. Signal
interface routines other than normally do not reset the action for the
signal caught. However, provides a way of specifying this behavior.
The parameters passed to the signal-catching function where is used
are:
int sig The signal number.
int code A word of information usually provided
by the hardware.
struct sigcontext *scp A pointer to the machine-dependent
structure sigcontext defined in
<signal.h>.
The parameters passed to the signal-catching function where is used and
is not specified are:
int sig The signal number.
The parameters passed to the signal-catching function where is used and
is specified are:
int sig The signal number.
siginfo_t *siginfop Information on why the signal was
generated.
void *contextp Can be cast to a pointer to a ucontext_t
to refer to the thread's context at the
time of the interruption.
Depending on the value of sig, code can be zero and/or scp can be The
meanings of code and scp and the conditions determining when they are
other than zero or are implementation-dependent. It is possible for
code to always be zero, and scp to always be
The pointer scp, siginfop, and contextp are valid only during the con‐
text of the signal-catching function.
Optional parameters can be omitted from the signal-catching function
parameter list, in which case the signal-catching function is exactly
compatible with UNIX System V. Truly portable software should not use
the optional parameters in signal-catching routines.
Upon return from the signal-catching function, the receiving process
resumes execution at the point where it was interrupted.
When a signal is caught during the execution of system calls such as or
on a slow device (such as a terminal, but not a file on a local
filesystem), during a system call or a system call that does not return
immediately because a previously stopped or zombie process already
exists, the signal-catching function is executed and the interrupted
system call returns a −1 to the calling process with set to
When any stop signal is generated for a process, pending signals for
that process are discarded. Conversely, when is generated for a
process, all pending stop signals for that process are discarded. When
is generated for a stopped process, the process is continued, even if
the signal is blocked or ignored. If is blocked and not ignored, the
signal remains pending until it is either unblocked or a stop signal is
generated.
Note: When any stop signal is posted to threads created with process
contention scope, using pending signals may not be discarded. Simi‐
larly, when is posted to threads created with process contention scope,
using pending stop signals may not be discarded. However, stop and
continue signals posted to threads created with system contention
scope, using will continue to adhere to the semantics described in the
preceding paragraph.
is sent by the system if an system call is unsuccessful and the origi‐
nal program has already been deleted.
Threads Considerations
The following summarizes the signal model for threads:
A signal mask which specifies the signals blocked from delivery
is associated with each thread.
The signal disposition, catch/ignore/default, is a process
attribute and is shared by all threads in the process.
If the signal action for a signal specifies termination, stop or
continue, all threads within the process are terminated, stopped
or continued, respectively. This is the case regardless of
whether the signal was directed at the process or a specific
thread within the process.
Signals which are generated by some action associated with a
particular thread, such as an invalid pointer dereference, will
be delivered to the thread which caused the generation of the
signal. These signals are referred to as synchronously gener‐
ated signals.
Signals that are posted to the process by or some asynchronous
event such as terminal activity will be delivered to exactly one
thread in the process which does not block delivery of the sig‐
nal; if there is more than one eligible thread, which thread the
signal is delivered to may not be able to be determined by an
application. If all threads in the process block the signal,
then the signal remains pending on the process until a thread
unblocks the signal, issues a call for the signal or sets the
signal disposition to ignore the signal. These signals are
referred to as asynchronously generated signals.
A thread can post a signal to a particular thread in the same
process using If the thread which the signal is posted to blocks
delivery of the signal, the signal remains pending on the
thread.
The function returns a union of the set of signals pending on
the process and on the calling thread.
Each PTHREAD_SCOPE_SYSTEM thread may define an alternate signal
handling stack. Use of alternate signal stacks in
PTHREAD_SCOPE_PROCESS threads will result in indeterminate
behavior.
Threadsafe Considerations
Refer to thread_safety(5) for a list of libc and libpthread interfaces
which are not thread-safe, cancellation points, cancel safe, async sig‐
nal safe, and async cancel safe.
WARNINGS
The signals and behave differently than those described above in the
list of signals in
The actions for these signals is modified as follows:
Setting the action
for to in a parent process prevents exiting chil‐
dren of the calling process from creating a zom‐
bie process. If the parent process executes the
function, the calling process blocks until all of
the child processes of the calling processes ter‐
minate. The function then returns a value of −1
with set to (see wait(2)).
If one of the signal interface routines is used
to set the action for to be caught (that is, a
function address is supplied) in a process that
currently has terminated (zombie) children, a
signal is delivered to the parent process immedi‐
ately.
Signal-catching functions set by are reset when
the signal is caught. These functions generally
reinstall themselves. If the function associated
with reinstalls itself before it has called one
of the child wait functions (such as or another
signal will be delivered and the handler immedi‐
ately invoked again (unless the signal is
masked). Thus, a signal-catching function for
should reinstall itself only after it has called
one of the child wait functions. (This similarly
applies to signal-catching functions set with
where SA_RESETHAND or SV_RESETHAND has been spec‐
ified.)
The signal is sent to all processes after a power
interruption when power is restored and the sys‐
tem has done all necessary reinitialization.
Processes restart by catching (or ignoring)
Applications that wish to recover from power
failures should catch and take whatever necessary
steps to reinitialize itself.
Some implementations do not generate Only systems
with nonvolatile memory can recover from power
failures.
The hardware program counter is not advanced when a trap occurs. If
the signal generated by a hardware trap is received by a signal-catch‐
ing function in the user program, the instruction that caused the trap
is re-executed upon return from the signal-catching function, causing
the trap again, unless program flow is altered by the signal-catching
function. For example, the routine (see setjmp(3C)) can be called.
Using ensures software portability across different hardware architec‐
tures.
If the signal generated by a hardware trap is not received by a signal-
catching function, that is, if the signal is masked or ignored, there
may be one of two results:
1. The instruction causing the trap is executed again, resulting in an
infinite program loop
2. The system detects the situation and causes the program to termi‐
nate.
AUTHOR
was developed by HP, AT&T, and the University of California, Berkeley.
SEE ALSOkill(1), init(1M), alarm(2), exit(2), ioctl(2), kill(2), lseek(2),
pause(2), select(2), sigaction(2), sigaltstack(2), siginterrupt(2),
signal(2), sigpending(2), sigprocmask(2), sigsuspend(2), sigwait(2),
umask(2), wait(2), waitid(2), abort(3C), setjmp(3C), sigset(3C),
core(4), thread_safety(5), termio(7), glossary(9).
STANDARDS CONFORMANCEsignal(5)
