Go to the previous, next section.
A signal is a software interrupt delivered to a process. The operating system uses signals to report exceptional situations to an executing program. Some signals report errors such as references to invalid memory addresses; others report asynchronous events, such as disconnection of a phone line.
The GNU C library defines a variety of signal types, each for a particular kind of event. Some kinds of events make it inadvisable or impossible for the program to proceed as usual, and the corresponding signals normally abort the program. Other kinds of signals that report harmless events are ignored by default.
If you anticipate an event that causes signals, you can define a handler function and tell the operating system to run it when that particular type of signal arrives.
Finally, one process can send a signal to another process; this allows a parent process to abort a child, or two related processes to communicate and synchronize.
This section explains basic concepts of how signals are generated, what happens after a signal is delivered, and how programs can handle signals.
A signal reports the occurrence of an exceptional event. These are some of the events that can cause (or generate, or raise) a signal:
kill or raise by the same process.
kill from another process. Signals are a limited but
useful form of interprocess communication.
Each of these kinds of events (excepting explicit calls to kill
and raise) generates its own particular kind of signal. The
various kinds of signals are listed and described in detail in
section Standard Signals.
In general, the events that generate signals fall into three major categories: errors, external events, and explicit requests.
An error means that a program has done something invalid and cannot
continue execution. But not all kinds of errors generate signals--in
fact, most do not. For example, opening a nonexistant file is an error,
but it does not raise a signal; instead, open returns -1.
In general, errors that are necessarily associated with certain library
functions are reported by returning a value that indicates an error.
The errors which raise signals are those which can happen anywhere in
the program, not just in library calls. These include division by zero
and invalid memory addresses.
An external event generally has to do with I/O or other processes. These include the arrival of input, the expiration of a timer, and the termination of a child process.
An explicit request means the use of a library function such as
kill whose purpose is specifically to generate a signal.
Signals may be generated synchronously or asynchronously. A synchronous signal pertains to a specific action in the program, and is delivered (unless blocked) during that action. Errors generate signals synchronously, and so do explicit requests by a process to generate a signal for that same process.
Asynchronous signals are generated by events outside the control of the process that receives them. These signals arrive at unpredictable times during execution. External events generate signals asynchronously, and so do explicit requests that apply to some other process.
A given type of signal is either typically synchrous or typically asynchronous. For example, signals for errors are typically synchronous because errors generate signals synchronously. But any type of signal can be generated synchronously or asynchronously with an explicit request.
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 section 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 section Specifying 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 it.
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 section 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 section 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.
This section lists the names for various standard kinds of signals and describes what kind of event they mean. Each signal name is a macro which stands for a positive integer--the signal number for that kind of signal. Your programs should never make assumptions about the numeric code for a particular kind of signal, but rather refer to them always by the names defined here. This is because the number for a given kind of signal can vary from system to system, but the meanings of the names are standardized and fairly uniform.
The signal names are defined in the header file `signal.h'.
The value of this symbolic constant is the total number of signals
defined. Since the signal numbers are allocated consecutively,
NSIG is also one greater than the largest defined signal number.
The following signals are generated when a serious program error is detected by the operating system or the computer itself. In general, all of these signals are indications that your program is seriously broken in some way, and there's usually no way to continue the computation which encountered the error.
Some programs handle program error signals in order to tidy up before terminating; for example, programs that turn off echoing of terminal input should handle program error signals in order to turn echoing back on. The handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See section Handlers That Terminate the Process.)
Termination is the sensible ultimate outcome from a program error in
most programs. However, programming systems such as Lisp that can load
compiled user programs might need to keep executing even if a user
program incurs an error. These programs have handlers which use
longjmp to return control to the command level.
The default action for all of these signals is to cause the process to
terminate. If you block or ignore these signals or establish handlers
for them that return normally, your program will probably break horribly
when such signals happen, unless they are generated by raise or
kill instead of a real error.
When one of these program error signals terminates a process, it also
writes a core dump file which records the state of the process at
the time of termination. The core dump file is named `core' and is
written in whichever directory is current in the process at the time.
(On the GNU system, you can specify the file name for core dumps with
the environment variable COREFILE.) The purpose of core dump
files is so that you can examine them with a debugger to investigate
what caused the error.
The SIGFPE signal reports a fatal arithmetic error. Although the
name is derived from "floating-point exception", this signal actually
covers all arithmetic errors, including division by zero and overflow.
If a program stores integer data in a location which is then used in a
floating-point operation, this often causes an "invalid operation"
exception, because the processor cannot recognize the data as a
floating-point number.
Actual floating-point exceptions are a complicated subject because there
are many types of exceptions with subtly different meanings, and the
SIGFPE signal doesn't distinguish between them. The IEEE
Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985)
defines various floating-point exceptions and requires conforming
computer systems to report their occurrences. However, this standard
does not specify how the exceptions are reported, or what kinds of
handling and control the operating system can offer to the programmer.
BSD systems provide the SIGFPE handler with an extra argument
that distinguishes various causes of the exception. In order to access
this argument, you must define the handler to accept two arguments,
which means you must cast it to a one-argument function type in order to
establish the handler. The GNU library does provide this extra
argument, but the value is meaningful only on operating systems that
provide the information (BSD systems and GNU systems).
FPE_INTOVF_TRAP
FPE_INTDIV_TRAP
FPE_SUBRNG_TRAP
FPE_FLTOVF_TRAP
FPE_FLTDIV_TRAP
FPE_FLTUND_TRAP
FPE_DECOVF_TRAP
The name of this signal is derived from "illegal instruction"; it
means your program is trying to execute garbage or a privileged
instruction. Since the C compiler generates only valid instructions,
SIGILL typically indicates that the executable file is corrupted,
or that you are trying to execute data. Some common ways of getting
into the latter situation are by passing an invalid object where a
pointer to a function was expected, or by writing past the end of an
automatic array (or similar problems with pointers to automatic
variables) and corrupting other data on the stack such as the return
address of a stack frame.
This signal is generated when a program tries to read or write outside the memory that is allocated for it. (Actually, the signals only occur when the program goes far enough outside to be detected by the system's memory protection mechanism.) The name is an abbreviation for "segmentation violation".
The most common way of getting a SIGSEGV condition is by
dereferencing a null or uninitialized pointer. A null pointer refers to
the address 0, and most operating systems make sure this address is
always invalid precisely so that dereferencing a null pointer will cause
SIGSEGV. (Some operating systems place valid memory at address
0, and dereferencing a null pointer does not cause a signal on these
systems.) As for uninitialized pointer variables, they contain random
addresses which may or may not be valid.
Another common way of getting into a SIGSEGV situation is when
you use a pointer to step through an array, but fail to check for the
end of the array.
This signal is generated when an invalid pointer is dereferenced. Like
SIGSEGV, this signal is typically the result of dereferencing an
uninitialized pointer. The difference between the two is that
SIGSEGV indicates an invalid access to valid memory, while
SIGBUS indicates an access to an invalid address. In particular,
SIGBUS signals often result from dereferencing a misaligned
pointer, such as referring to a four-word integer at an address not
divisible by four. (Each kind of computer has its own requirements for
address alignment.)
The name of this signal is an abbreviation for "bus error".
This signal indicates an error detected by the program itself and
reported by calling abort. See section Aborting a Program.
These signals are all used to tell a process to terminate, in one way or another. They have different names because they're used for slightly different purposes, and programs might want to handle them differently.
The reason for handling these signals is usually so your program can tidy up as appropriate before actually terminating. For example, you might want to save state information, delete temporary files, or restore the previous terminal modes. Such a handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See section Handlers That Terminate the Process.)
The (obvious) default action for all of these signals is to cause the process to terminate.
The SIGHUP ("hang-up") signal is used to report that the user's
terminal is disconnected, perhaps because a network or telephone
connection was broken. For more information about this, see section Control Modes.
This signal is also used to report the termination of the controlling process on a terminal to jobs associated with that session; this termination effectively disconnects all processes in the session from the controlling terminal. For more information, see section Termination Internals.
The SIGINT ("program interrupt") signal is sent when the user
types the INTR character (normally C-c). See section Special Characters, for information about terminal driver support for
C-c.
The SIGQUIT signal is similar to SIGINT, except that it's
controlled by a different key--the QUIT character, usually
C-\---and produces a core dump when it terminates the process,
just like a program error signal. You can think of this as a
program error condition "detected" by the user.
See section Program Error Signals, for information about core dumps. See section Special Characters, for information about terminal driver support.
Certain kinds of cleanups are best omitted in handling SIGQUIT.
For example, if the program creates temporary files, it should handle
the other termination requests by deleting the temporary files. But it
is better for SIGQUIT not to delete them, so that the user can
examine them in conjunction with the core dump.
The SIGTERM signal is a generic signal used to cause program
termination. Unlike SIGKILL, this signal can be blocked,
handled, and ignored.
The shell command kill generates SIGTERM by default.
The SIGKILL signal is used to cause immediate program termination.
It cannot be handled or ignored, and is therefore always fatal. It is
also not possible to block this signal.
This signal is generated only by explicit request. Since it cannot be
handled, you should generate it only as a last resort, after first
trying a less drastic method such as C-c or SIGTERM. If a
process does not respond to any other termination signals, sending it a
SIGKILL signal will almost always cause it to go away.
In fact, if SIGKILL fails to terminate a process, that by itself
constitutes an operating system bug which you should report.
These signals are used to indicate the expiration of timers. See section Setting an Alarm, for information about functions that cause these signals to be sent.
The default behavior for these signals is to cause program termination. This default is rarely useful, but no other default would be useful; most of the ways of using these signals would require handler functions in any case.
This signal typically indicates expiration of a timer that measures real
or clock time. It is used by the alarm function, for example.
This signal typically indicates expiration of a timer that measures CPU time used by the current process. The name is an abbreviation for "virtual time alarm".
This signal is typically indicates expiration of a timer that measures both CPU time used by the current process, and CPU time expended on behalf of the process by the system. Such a timer is used to implement code profiling facilities, hence the name of this signal.
The signals listed in this section are used in conjunction with
asynchronous I/O facilities. You have to take explicit action by
calling fcntl to enable a particular file descriptior to generate
these signals (see section Interrupt-Driven Input). The default action for these
signals is to ignore them.
This signal is sent when a file descriptor is ready to perform input or output.
On most operating systems, terminals and sockets are the only kinds of
files that can generate SIGIO; other kinds, including ordinary
files, never generate SIGIO even if you ask them to.
This signal is sent when "urgent" or out-of-band data arrives on a socket. See section Out-of-Band Data.
These signals are used to support job control. If your system doesn't support job control, then these macros are defined but the signals themselves can't be raised or handled.
You should generally leave these signals alone unless you really understand how job control works. See section Job Control.
This signal is sent to a parent process whenever one of its child processes terminates or stops.
The default action for this signal is to ignore it. If you establish a
handler for this signal while there are child processes that have
terminated but not reported their status via wait or
waitpid (see section Process Completion), whether your new handler
applies to those processes or not depends on the particular operating
system.
You can send a SIGCONT signal to a process to make it continue.
The default behavior for this signal is to make the process continue if
it is stopped, and to ignore it otherwise.
Most programs have no reason to handle SIGCONT; they simply
resume execution without realizing they were ever stopped. You can use
a handler for SIGCONT to make a program do something special when
it is stopped and continued--for example, to reprint a prompt when it
is suspended while waiting for input.
The SIGSTOP signal stops the process. It cannot be handled,
ignored, or blocked.
The SIGTSTP signal is an interactive stop signal. Unlike
SIGSTOP, this signal can be handled and ignored.
Your program should handle this signal if you have a special need to
leave files or system tables in a secure state when a process is
stopped. For example, programs that turn off echoing should handle
SIGTSTP so they can turn echoing back on before stopping.
This signal is generated when the user types the SUSP character (normally C-z). For more information about terminal driver support, see section Special Characters.
A process cannot read from the the user's terminal while it is running
as a background job. When any process in a background job tries to
read from the terminal, all of the processes in the job are sent a
SIGTTIN signal. The default action for this signal is to
stop the process. For more information about how this interacts with
the terminal driver, see section Access to the Controlling Terminal.
This is similar to SIGTTIN, but is generated when a process in a
background job attempts to write to the terminal or set its modes.
Again, the default action is to stop the process.
While a process is stopped, no more signals can be delivered to it until
it is continued, except SIGKILL signals and (obviously)
SIGCONT signals. The SIGKILL signal always causes
termination of the process and can't be blocked or ignored. You can
block or ignore SIGCONT, but it always causes the process to
be continued anyway if it is stopped. Sending a SIGCONT signal
to a process causes any pending stop signals for that process to be
discarded. Likewise, any pending SIGCONT signals for a process
are discarded when it receives a stop signal.
When a process in an orphaned process group (see section Orphaned Process Groups) receives a SIGTSTP, SIGTTIN, or SIGTTOU
signal and does not handle it, the process does not stop. Stopping the
process would be unreasonable since there would be no way to continue
it. What happens instead depends on the operating system you are
using. Some systems may do nothing; others may deliver another signal
instead, such as SIGKILL or SIGHUP.
These signals are used to report various other conditions. The default action for all of them is to cause the process to terminate.
If you use pipes or FIFOs, you have to design your application so that
one process opens the pipe for reading before another starts writing.
If the reading process never starts, or terminates unexpectedly, writing
to the pipe or FIFO raises a SIGPIPE signal. If SIGPIPE
is blocked, handled or ignored, the offending call fails with
EPIPE instead.
Pipes and FIFO special files are discussed in more detail in section Pipes and FIFOs.
Another cause of SIGPIPE is when you try to output to a socket
that isn't connected. See section Sending Data.
The SIGUSR1 and SIGUSR2 signals are set aside for you to
use any way you want. They're useful for interprocess communication.
Since these signals are normally fatal, you should write a signal handler
for them in the program that receives the signal.
There is an example showing the use of SIGUSR1 and SIGUSR2
in section Signaling Another Process.
Particular operating systems support additional signals not listed above. The ANSI C standard reserves all identifiers beginning with `SIG' followed by an uppercase letter for the names of signals. You should consult the documentation or header files for your particular operating system and processor type to find out about the specific signals it supports.
For example, some systems support extra signals which correspond to hardware traps. Some other kinds of signals commonly supported are used to implement limits on CPU time or file system usage, asynchronous changes to terminal configuration, and the like. Systems may also define signal names that are aliases for standard signal names.
You can generally assume that the default action (or the action set up by the shell) for implementation-defined signals is reasonable, and not worry about them yourself. In fact, it's usually a bad idea to ignore or block signals you don't know anything about, or try to establish a handler for signals whose meanings you don't know.
Here are some of the other signals found on commonly used operating systems:
SIGCLD
SIGCHLD.
SIGTRAP
SIGIOT
SIGABRT.
Default action is to dump core.
SIGEMT
SIGSYS
SIGPOLL
SIGIO.
SIGXCPU
SIGXFSZ
SIGWINCH
We mentioned above that the shell prints a message describing the signal
that terminated a child process. The clean way to print a message
describing a signal is to use the functions strsignal and
psignal. These functions use a signal number to specify which
kind of signal to describe. The signal number may come from the
termination status of a child process (see section Process Completion) or it
may come from a signal handler in the same process.
Function: char * strsignal (int signum)
This function returns a pointer to a statically-allocated string containing a message describing the signal signum. You should not modify the contents of this string; and, since it can be rewritten on subsequent calls, you should save a copy of it if you need to reference it later.
This function is a GNU extension, declared in the header file `string.h'.
Function: void psignal (int signum, const char *message)
This function prints a message describing the signal signum to the
standard error output stream stderr; see section Standard Streams.
If you call psignal with a message that is either a null
pointer or an empty string, psignal just prints the message
corresponding to signum, adding a trailing newline.
If you supply a non-null message argument, then psignal
prefixes its output with this string. It adds a colon and a space
character to separate the message from the string corresponding
to signum.
This function is a BSD feature, declared in the header file `stdio.h'.
There is also an array sys_siglist which contains the messages
for the various signal codes. This array exists on BSD systems, unlike
strsignal.
The simplest way to change the action for a signal is to use the
signal function. You can specify a built-in action (such as to
ignore the signal), or you can establish a handler.
The GNU library also implements the more versatile sigaction
facility. This section describes both facilities and gives suggestions
on which to use when.
The signal function provides a simple interface for establishing
an action for a particular signal. The function and associated macros
are declared in the header file `signal.h'.
This is the type of signal handler functions. Signal handlers take one
integer argument specifying the signal number, and have return type
void. So, you should define handler functions like this:
void handler (int signum) { ... }
The name sighandler_t for this data type is a GNU extension.
Function: sighandler_t signal (int signum, sighandler_t action)
The signal function establishes action as the action for
the signal signum.
The first argument, signum, identifies the signal whose behavior you want to control, and should be a signal number. The proper way to specify a signal number is with one of the symbolic signal names described in section Standard Signals---don't use an explicit number, because the numerical code for a given kind of signal may vary from operating system to operating system.
The second argument, action, specifies the action to use for the signal signum. This can be one of the following:
SIG_DFL
SIG_DFL specifies the default action for the particular signal.
The default actions for various kinds of signals are stated in
section Standard Signals.
SIG_IGN
SIG_IGN specifies that the signal should be ignored.
Your program generally should not ignore signals that represent serious
events or that are normally used to request termination. You cannot
ignore the SIGKILL or SIGSTOP signals at all. You can
ignore program error signals like SIGSEGV, but ignoring the error
won't enable the program to continue executing meaningfully. Ignoring
user requests such as SIGINT, SIGQUIT, and SIGTSTP
is unfriendly.
When you do not wish signals to be delivered during a certain part of the program, the thing to do is to block them, not ignore them. See section Blocking Signals.
handler
For more information about defining signal handler functions, see section Defining Signal Handlers.
If you set the action for a signal to SIG_IGN, or if you set it
to SIG_DFL and the default action is to ignore that signal, then
any pending signals of that type are discarded (even if they are
blocked). Discarding the pending signals means that they will never be
delivered, not even if you subsequently specify another action and
unblock this kind of signal.
The signal function returns the action that was previously in
effect for the specified signum. You can save this value and
restore it later by calling signal again.
If signal can't honor the request, it returns SIG_ERR
instead. The following errno error conditions are defined for
this function:
EINVAL
SIGKILL or SIGSTOP.
Here is a simple example of setting up a handler to delete temporary files when certain fatal signals happen:
#include <signal.h>
void
termination_handler (int signum)
{
struct temp_file *p;
for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}
int
main (void)
{
...
if (signal (SIGINT, termination_handler) == SIG_IGN)
signal (SIGINT, SIG_IGN);
if (signal (SIGHUP, termination_handler) == SIG_IGN)
signal (SIGHUP, SIG_IGN);
if (signal (SIGTERM, termination_handler) == SIG_IGN)
signal (SIGTERM, SIG_IGN);
...
}
Note how if a given signal was previously set to be ignored, this code avoids altering that setting. This is because non-job-control shells often ignore certain signals when starting children, and it is important for the children to respect this.
We do not handle SIGQUIT or the program error signals in this
example because these are designed to provide information for debugging
(a core dump), and the temporary files may give useful information.
Function: sighandler_t ssignal (int signum, sighandler_t action)
The ssignal function does the same thing as signal; it is
provided only for compatibility with SVID.
The value of this macro is used as the return value from signal
to indicate an error.
The sigaction function has the same basic effect as
signal: to specify how a signal should be handled by the process.
However, sigaction offers more control, at the expense of more
complexity. In particular, sigaction allows you to specify
additional flags to control when the signal is generated and how the
handler is invoked.
The sigaction function is declared in `signal.h'.
Structures of type struct sigaction are used in the
sigaction function to specify all the information about how to
handle a particular signal. This structure contains at least the
following members:
sighandler_t sa_handler
signal function. The value can be SIG_DFL,
SIG_IGN, or a function pointer. See section Basic Signal Handling.
sigset_t sa_mask
sa_mask. If you want that signal not to be blocked within its
handler, you must write code in the handler to unblock it.
int sa_flags
sigaction.
Function: int sigaction (int signum, const struct sigaction *action, struct sigaction *old_action)
The action argument is used to set up a new action for the signal
signum, while the old_action argument is used to return
information about the action previously associated with this symbol.
(In other words, old_action has the same purpose as the
signal function's return value--you can check to see what the
old action in effect for the signal was, and restore it later if you
want.)
Either action or old_action can be a null pointer. If old_action is a null pointer, this simply suppresses the return of information about the old action. If action is a null pointer, the action associated with the signal signum is unchanged; this allows you to inquire about how a signal is being handled without changing that handling.
The return value from sigaction is zero if it succeeds, and
-1 on failure. The following errno error conditions are
defined for this function:
EINVAL
SIGKILL or SIGSTOP.
signal and sigaction
It's possible to use both the signal and sigaction
functions within a single program, but you have to be careful because
they can interact in slightly strange ways.
The sigaction function specifies more information than the
signal function, so the return value from signal cannot
express the full range of sigaction possibilities. Therefore, if
you use signal to save and later reestablish an action, it may
not be able to reestablish properly a handler that was established with
sigaction.
To avoid having problems as a result, always use sigaction to
save and restore a handler if your program uses sigaction at all.
Since sigaction is more general, it can properly save and
reestablish any action, regardless of whether it was established
originally with signal or sigaction.
If you establish an action with signal and then examine it with
sigaction, the handler address that you get may not be the same
as what you specified with signal. It may not even be suitable
for use as an action argument with signal. But you can rely on
using it as an argument to sigaction.
So, you're better off using one or the other of the mechanisms consistently within a single program.
Portability Note: The basic signal function is a feature
of ANSI C, while sigaction is part of the POSIX.1 standard. If
you are concerned about portability to non-POSIX systems, then you
should use the signal function instead.
sigaction Function Example
In section Basic Signal Handling, we gave an example of establishing a
simple handler for termination signals using signal. Here is an
equivalent example using sigaction:
#include <signal.h>
void
termination_handler (int signum)
{
struct temp_file *p;
for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}
int
main (void)
{
...
struct sigaction new_action, old_action;
/* Set up the structure to specify the new action. */
new_action.sa_handler = termination_handler;
sigemptyset (&new_action.sa_mask);
new_action.sa_flags = 0;
sigaction (SIGINT, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGINT, &new_action, NULL);
sigaction (SIGHUP, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGHUP, &new_action, NULL);
sigaction (SIGTERM, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGTERM, &new_action, NULL);
...
}
The program just loads the new_action structure with the desired
parameters and passes it in the sigaction call. The usage of
sigemptyset is described later; see section Blocking Signals.
As in the example using signal, we avoid handling signals
previously set to be ignored. Here we can avoid altering the signal
handler even momentarily, by using the feature of sigaction that
lets us examine the current action without specifying a new one.
Here is another example. It retrieves information about the current
action for SIGINT without changing that action.
struct sigaction query_action; if (sigaction (SIGINT, NULL, &query_action) < 0) /*sigactionreturns -1 in case of error. */ else if (query_action.sa_handler == SIG_DFL) /*SIGINTis handled in the default, fatal manner. */ else if (query_action.sa_handler == SIG_IGN) /*SIGINTis ignored. */ else /* A programmer-defined signal handler is in effect. */
sigaction
The sa_flags member of the sigaction structure is a
catch-all for special features. Most of the time, SA_RESTART is
a good value to use for this field.
The value of sa_flags is interpreted as a bit mask. Thus, you
should choose the flags you want to set, OR those flags together,
and store the result in the sa_flags member of your
sigaction structure.
Each signal number has its own set of flags. Each call to
sigaction affects one particular signal number, and the flags
that you specify apply only to that particular signal.
In the GNU C library, establishing a handler with signal sets all
the flags to zero except for SA_RESTART, whose value depends on
the settings you have made with siginterrupt. See section Primitives Interrupted by Signals, to see what this is about.
These macros are defined in the header file `signal.h'.
This flag is meaningful only for the SIGCHLD signal. When the
flag is set, the system delivers the signal for a terminated child
process but not for one that is stopped. By default, SIGCHLD is
delivered for both terminated children and stopped children.
Setting this flag for a signal other than SIGCHLD has no effect.
If this flag is set for a particular signal number, the system uses the signal stack when delivering that kind of signal. See section BSD Signal Handling.
This flag controls what happens when a signal is delivered during
certain primitives (such as open, read or write),
and the signal handler returns normally. There are two alternatives:
the library function can resume, or it can return failure with error
code EINTR.
The choice is controlled by the SA_RESTART flag for the
particular kind of signal that was delivered. If the flag is set,
returning from a handler resumes the library function. If the flag is
clear, returning from a handler makes the function fail.
See section Primitives Interrupted by Signals.
When a new process is created (see section Creating a Process), it inherits
handling of signals from its parent process. However, when you load a
new process image using the exec function (see section Executing a File), any signals that you've defined your own handlers for revert to
their SIG_DFL handling. (If you think about it a little, this
makes sense; the handler functions from the old program are specific to
that program, and aren't even present in the address space of the new
program image.) Of course, the new program can establish its own
handlers.
When a program is run by a shell, the shell normally sets the initial
actions for the child process to SIG_DFL or SIG_IGN, as
appropriate. It's a good idea to check to make sure that the shell has
not set up an initial action of SIG_IGN before you establish your
own signal handlers.
Here is an example of how to establish a handler for SIGHUP, but
not if SIGHUP is currently ignored:
...
struct sigaction temp;
sigaction (SIGHUP, NULL, &temp);
if (temp.sa_handler != SIG_IGN)
{
temp.sa_handler = handle_sighup;
sigemptyset (&temp.sa_mask);
sigaction (SIGHUP, &temp, NULL);
}
This section describes how to write a signal handler function that can
be established with the signal or sigaction functions.
A signal handler is just a function that you compile together with the
rest of the program. Instead of directly invoking the function, you use
signal or sigaction to tell the operating system to call
it when a signal arrives. This is known as establishing the
handler. See section Specifying Signal Actions.
There are two basic strategies you can use in signal handler functions:
You need to take special care in writing handler functions because they can be called asynchronously. That is, a handler might be called at any point in the program, unpredictably. If two signals arrive during a very short interval, one handler can run within another. This section describes what your handler should do, and what you should avoid.
Handlers which return normally are usually used for signals such as
SIGALRM and the I/O and interprocess communication signals. But
a handler for SIGINT might also return normally after setting a
flag that tells the program to exit at a convenient time.
It is not safe to return normally from the handler for a program error signal, because the behavior of the program when the handler function returns is not defined after a program error. See section Program Error Signals.
Handlers that return normally must modify some global variable in order
to have any effect. Typically, the variable is one that is examined
periodically by the program during normal operation. Its data type
should be sig_atomic_t for reasons described in section Atomic Data Access and Signal Handling.
Here is a simple example of such a program. It executes the body of
the loop until it has noticed that a SIGALRM signal has arrived.
This technique is useful because it allows the iteration in progress
when the signal arrives to complete before the loop exits.
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
/* This flag controls termination of the main loop. */
volatile sig_atomic_t keep_going = 1;
/* The signal handler just clears the flag and re-enables itself. */
void
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}
void
do_stuff (void)
{
puts ("Doing stuff while waiting for alarm....");
}
int
main (void)
{
/* Establish a handler for SIGALRM signals. */
signal (SIGALRM, catch_alarm);
/* Set an alarm to go off in a little while. */
alarm (2);
/* Check the flag once in a while to see when to quit. */
while (keep_going)
do_stuff ();
return EXIT_SUCCESS;
}
Handler functions that terminate the program are typically used to cause orderly cleanup or recovery from program error signals and interactive interrupts.
The cleanest way for a handler to terminate the process is to raise the same signal that ran the handler in the first place. Here is how to do this:
volatile sig_atomic_t fatal_error_in_progress = 0;
void
fatal_error_signal (int sig)
{
/* Since this handler is established for more than one kind of signal,
it might still get invoked recursively by delivery of some other kind
of signal. Use a static variable to keep track of that. */
if (fatal_error_in_progress)
raise (sig);
fatal_error_in_progress = 1;
/* Now do the clean up actions:
- reset terminal modes
- kill child processes
- remove lock files */
...
/* Now reraise the signal. Since the signal is blocked,
it will receive its default handling, which is
to terminate the process. We could just call
exit or abort, but reraising the signal
sets the return status from the process correctly. */
raise (sig);
}
You can do a nonlocal transfer of control out of a signal handler using
the setjmp and longjmp facilities (see section Non-Local Exits).
When the handler does a nonlocal control transfer, the part of the program that was running will not continue. If this part of the program was in the middle of updating an important data structure, the data structure will remain inconsistent. Since the program does not terminate, the inconsistency is likely to be noticed later on.
There are two ways to avoid this problem. One is to block the signal for the parts of the program that update important data structures. Blocking the signal delays its delivery until it is unblocked, once the critical updating is finished. See section Blocking Signals.
The other way to re-initialize the crucial data structures in the signal handler, or make their values consistent.
Here is a rather schematic example showing the reinitialization of one global variable.
#include <signal.h>
#include <setjmp.h>
jmp_buf return_to_top_level;
volatile sig_atomic_t waiting_for_input;
void
handle_sigint (int signum)
{
/* We may have been waiting for input when the signal arrived,
but we are no longer waiting once we transfer control. */
waiting_for_input = 0;
longjmp (return_to_top_level, 1);
}
int
main (void)
{
...
signal (SIGINT, sigint_handler);
...
while (1) {
prepare_for_command ();
if (setjmp (return_to_top_level) == 0)
read_and_execute_command ();
}
}
/* Imagine this is a subroutine used by various commands. */
char *
read_data ()
{
if (input_from_terminal) {
waiting_for_input = 1;
...
waiting_for_input = 0;
} else {
...
}
}
What happens if another signal arrives when your signal handler function is running?
When the handler for a particular signal is invoked, that signal is
normally blocked until the handler returns. That means that if two
signals of the same kind arrive close together, the second one will be
held until the first has been handled. (The handler can explicitly
unblock the signal using sigprocmask, if you want to allow more
signals of this type to arrive; see section Process Signal Mask.)
However, your handler can still be interrupted by delivery of another
kind of signal. To avoid this, you can use the sa_mask member of
the action structure passed to sigaction to explicitly specify
which signals should be blocked while the signal handler runs. These
signals are in addition to the signal for which the handler was invoked,
and any other signals that are normally blocked by the process.
See section Blocking Signals for a Handler.
Portability Note: Always use sigaction to establish a
handler for a signal that you expect to receive asynchronously, if you
want your program to work properly on System V Unix. On this system,
the handling of a signal whose handler was established with
signal automatically sets the signal's action back to
SIG_DFL, and the handler must re-establish itself each time it
runs. This practice, while inconvenient, does work when signals cannot
arrive in succession. However, if another signal can arrive right away,
it may arrive before the handler can re-establish itself. Then the
second signal would receive the default handling, which could terminate
the process.
If multiple signals of the same type are delivered to your process before your signal handler has a chance to be invoked at all, the handler may only be invoked once, as if only a single signal had arrived. In effect, the signals merge into one. This situation can arise when the signal is blocked, or in a multiprocessing environment where the system is busy running some other processes while the signals are delivered. This means, for example, that you cannot reliably use a signal handler to count signals. The only distinction you can reliably make is whether at least one signal has arrived since a given time in the past.
Here is an example of a handler for SIGCHLD that compensates for
the fact that the number of signals recieved may not equal the number of
child processes generate them. It assumes that the program keeps track
of all the child processes with a chain of structures as follows:
struct process
{
struct process *next;
/* The process ID of this child. */
int pid;
/* The descriptor of the pipe or pseudo terminal
on which output comes from this child. */
int input_descriptor;
/* Nonzero if this process has stopped or terminated. */
sig_atomic_t have_status;
/* The status of this child; 0 if running,
otherwise a status value from waitpid. */
int status;
};
struct process *process_list;
This example also uses a flag to indicate whether signals have arrived since some time in the past--whenever the program last cleared it to zero.
/* Nonzero means some child's status has changed
so look at process_list for the details. */
int process_status_change;
Here is the handler itself:
void
sigchld_handler (int signo)
{
int old_errno = errno;
while (1) {
register int pid;
int w;
struct process *p;
/* Keep asking for a status until we get a definitive result. */
do
{
errno = 0;
pid = waitpid (WAIT_ANY, &w, WNOHANG | WUNTRACED);
}
while (pid <= 0 && errno == EINTR);
if (pid <= 0) {
/* A real failure means there are no more
stopped or terminated child processes, so return. */
errno = old_errno;
return;
}
/* Find the process that signaled us, and record its status. */
for (p = process_list; p; p = p->next)
if (p->pid == pid) {
p->status = w;
/* Indicate that the status field
has data to look at. We do this only after storing it. */
p->have_status = 1;
/* If process has terminated, stop waiting for its output. */
if (WIFSIGNALED (w) || WIFEXITED (w))
if (p->input_descriptor)
FD_CLR (p->input_descriptor, &input_wait_mask);
/* The program should check this flag from time to time
to see if there is any news in process_list. */
++process_status_change;
}
/* Loop around to handle all the processes
that have something to tell us. */
}
}
Here is the proper way to check the flag process_status_change:
if (process_status_change) {
struct process *p;
process_status_change = 0;
for (p = process_list; p; p = p->next)
if (p->have_status) {
... Examine p->status ...
}
}
It is vital to clear the flag before examining the list; otherwise, if a signal were delivered just before the clearing of the flag, and after the appropriate element of the process list had been checked, the status change would go unnoticed until the next signal arrived to set the flag again. You could, of course, avoid this problem by blocking the signal while scanning the list, but it is much more elegant to guarantee correctness by doing things in the right order.
The loop which checks process status avoids examining p->status
until it sees that status has been validly stored. This is to make sure
that the status cannot change in the middle of accessing it. Once
p->have_status is set, it means that the child process is stopped
or terminated, and in either case, it cannot stop or terminate again
until the program has taken notice. See section Atomic Usage Patterns, for more
information about coping with interruptions during accessings of a
variable.
Here is another way you can test whether the handler has run since the last time you checked. This technique uses a counter which is never changed outside the handler. Instead of clearing the count, the program remembers the previous value and sees whether it has changed since the previous check. The advantage of this method is that different parts of the program can check independently, each part checking whether there has been a signal since that part last checked.
sig_atomic_t process_status_change;
sig_atomic_t last_process_status_change;
...
{
sig_atomic_t prev = last_process_status_change;
last_process_status_change = process_status_change;
if (last_process_status_change != prev) {
struct process *p;
for (p = process_list; p; p = p->next)
if (p->have_status) {
... Examine p->status ...
}
}
}
Handler functions usually don't do very much. The best practice is to
write a handler that does nothing but set an external variable that the
program checks regularly, and leave all serious work to the program.
This is best because the handler can be called at asynchronously, at
unpredictable times--perhaps in the middle of a system call, or even
between the beginning and the end of a C operator that requires multiple
instructions. The data structures being manipulated might therefore be
in an inconsistent state when the handler function is invoked. Even
copying one int variable into another can take two instructions
on most machines.
This means you have to be very careful about what you do in a signal handler.
volatile. This tells the compiler that
the value of the variable might change asynchronously, and inhibits
certain optimizations that would be invalidated by such modifications.
A function can be non-reentrant if it uses memory that is not on the stack.
For example, suppose that the signal handler uses gethostbyname.
This function returns its value in a static object, reusing the same
object each time. If the signal happens to arrive during a call to
gethostbyname, or even after one (while the program is still
using the value), it will clobber the value that the program asked for.
However, if the program does not use gethostbyname or any other
function that returns information in the same object, or if it always
blocks signals around each use, then you are safe.
There are a large number of library functions that return values in a fixed object, always reusing the same object in this fashion, and all of them cause the same problem.