NAME
signal.h - Contains definitions and variables used by signal
functions
DESCRIPTION
The /usr/include/signal.h file defines the following sig-
nals:
SIGHUP 1 Hangup.
SIGINT 2 Interrupt.
SIGQUIT 3 Quit.*
SIGILL 4 Invalid instruction (not reset when caught).*
SIGTRAP 5 Trace trap (not reset when caught).*
SIGABRT 6 End process (see the abort() function).*
SIGEMT 7 EMT instruction.
SIGFPE 8 Arithmetic exception, integer divide by 0 (zero), or
floating-point exception.*
SIGKILL 9 Kill (cannot be caught or ignored).
SIGBUS 10 Specification exception. *
SIGSEGV 11 Segmentation violation. *
SIGSYS 12 Invalid parameter to system call. *
SIGPIPE 13 Write on a pipe when there is no process to read it.
SIGALRM 14 Alarm clock.
SIGTERM 15 Software termination signal.
SIGURG 16 Urgent condition on I/O channel. +
SIGSTOP 17 Stop (cannot be caught or ignored). @
SIGTSTP 18 Interactive stop. @
SIGCONT 19 Continue if stopped (cannot be caught or ignored). !
SIGCHLD 20 To parent on child stop or exit. +
SIGTTIN 21 Background read attempted from control terminal. @
SIGTTOU 22 Background write attempted from control terminal. @
SIGIO 23 Input/Output possible or completed. +
SIGXCPU 24 CPU time limit exceeded (see the setrlimit() function).
SIGXFSZ 25 File size limit exceeded (see the setrlimit() function).
SIGVTALRM 26 Virtual time alarm (see the setitimer() function).
SIGPROF 27 Profiling time alarm (see the setitimer() function).
SIGWINCH 28 Window size change. +
SIGINFO 29 Information request +
SIGUSR1 30 User-defined signal 1.
SIGUSR2 31 User-defined signal 2.
The symbols in the preceding table have the following mean-
ing:
* Default action includes creating a core dump file.
@ Default action is to stop the process receiving these
signals.
! Default action is to restart or continue the process
receiving these signals.
+ Default action is to ignore these signals.
The three types of actions that can be associated with a
signal: SIG_DFL, SIG_IGN, or a pointer to a function are
described as follows:
SIG_DFL - Default action: signal-specific default action.
Except for those signal numbers marked with a +, @, or
!, the default action for a signal is to end the
receiving process with all of the consequences
described in the _exit() system call. In addition, a
memory image file is created in the current directory
of the receiving process if the signal parameter is one
for which an asterisk appears in the preceding list and
the following conditions are met:
o The effective user ID and the real user ID of the
receiving process are equal.
o An ordinary file named core exists in the current
directory and is writable, or it can be created.
If the file must be created, it will have the fol-
lowing properties:
- The access permission code 0666 (0x1B6),
modified by the file creation mask (see the
umask() function).
- A file owner ID that is the same as the
effective user ID of the receiving process.
- A file group ID that is the same as the
effective group ID of the receiving process.
For signal numbers marked with an !, the default action
is to restart the receiving process if it is stopped,
or to continue execution of the receiving process.
For signal numbers marked with an @, the default action
is to stop the execution of the receiving process tem-
porarily. When a process stops, a SIGCHLD signal is
sent to its parent process, unless the parent process
has set the SA_NOCLDSTOP bit. While a process is
stopped, any additional signals that are sent to the
process are not delivered until the process is contin-
ued. An exception to this is SIGKILL, which always ter-
minates the receiving process. Another exception is
SIGCONT, which always causes the receiving process to
restart or continue running. A process whose parent has
ended shall be sent a SIGKILL signal if the SIGTSTP,
SIGTTIN, or SIGTTOU signals are generated for that
process.
For signal numbers marked with a +, the default action
is to ignore the signal. In this case, delivery of the
signal has no effect on the receiving process.
If a signal action is set to SIG_DFL while the signal
is pending, the signal remains pending.
SIG_IGN - Ignore signal.
Delivery of the signal has no effect on the receiving pro-
cess. If a signal action is set to SIG_IGN while the signal
is pending, the pending signal is discarded.
Note that the SIGKILL, SIGSTOP, and SIGCONT signals cannot
be ignored.
pointer to a function - Catch signal.
Upon delivery of the signal, the receiving process is to run
the signal-catching function specified by the pointer to
function. The signal-handler subroutine can be declared as
follows:
void handler(signal)
int signal;
The signal parameter is the signal number.
A new signal mask is calculated and installed for the dura-
tion of the signal-catching function (or until sigprocmask()
or sigsuspend() system calls are made). This mask is formed
by taking the union of the process signal mask, the mask
associated with the action for the signal being delivered,
and a mask corresponding to the signal being delivered. The
mask associated with the signal-catching function is not
allowed to block those signals that cannot be ignored. This
is enforced by the kernel without causing an error to be
indicated. If and when the signal-catching function returns,
the original signal mask is restored (modified by any sig-
procmask() calls that were made since the signal-catching
function was called) and the receiving process resumes exe-
cution at the point it was interrupted.
The signal-catching function can cause the process to resume
in a different context by calling the longjmp() subroutine.
When the longjmp() subroutine is called, the process leaves
the signal stack, if it is currently on it, and restores the
process signal mask to the state when the corresponding
setjmp() call was made.
Once an action is installed for a specific signal, it
remains installed until another action is explicitly
requested (by another call to the sigaction() system call),
or until one of the exec system calls is called.
If a signal action is set to a pointer to a function while
the signal is pending, the signal remains pending.
When signal-catching functions are invoked asynchronously
with process execution, the behavior of some of the func-
tions defined by this standard is unspecified if they are
called from a signal-catching function. The following set
of functions are reentrant with respect to signals (that is,
applications can invoke them, without restriction, from
signal-catching functions):
_exit(), access(), alarm(), chdir(), chmod(), chown(),
close(), creat(), dup2(), dup(), exec(), fcntl(),
fork(), fstat(), getegid(), geteuid(), getgid(), get-
groups(), getpgrp(), getpid(), getppid(), getuid(),
kill(), link(), lseek(), mkdir(), mkfifo(), open(),
pause(), pipe(), read(), rename(), rmdir(), setgid(),
setpgrp(), setuid(), sigaction(), sigaddset(), sigdel-
set(), sigfillset(), siginitset(), sigismember(), sig-
nal(), sigpending(), sigprocmask(), sigsuspend(),
sleep(), statx(), tcdrain(), tcflow(), tcflush(),
tcgetattr(), tcgetprgp(), tcsendbreak(), tcsetattr(),
tcsetpgrp(), time(), times(), umask(), uname(),
unlink(), ustat(), utime(), wait2(), wait(), write().
All other system calls should not be called from signal-
catching functions since their behavior is undefined.
RELATED INFORMATION
Functions: sigaction(2), sigblock(2), sigemptyset(3),
siginterrupt(3), siglongjmp(3), sigpause(3), sigpending(2),
sigprocmask(2), sigreturn(2), sigset(3), sigsetjmp(3),
sigstack(2), sigsuspend(2), sigvec(2), sigwait(3)
Acknowledgement and Disclaimer