signal

Sommaire

NAME

signal - ANSI C signal handling

SYNOPSIS

#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

DESCRIPTION

The behavior of signal() varies across Unix versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. See Portability below.

signal() sets the disposition of the signal signum to handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined function (a "signal handler").

If the signal signum is delivered to the process, then one of the following happens:

*
If the disposition is set to SIG_IGN, then the signal is ignored.
*
If the disposition is set to SIG_DFL, then the default action associated with the signal (see signal(7)) occurs.
*
If the disposition is set to a function, then first either the disposition is reset to SIG_DFL, or the signal is blocked (see Portability below), and then handler is called with argument signum. If invocation of the handler caused the signal to be blocked, then the signal is unblocked upon return from the handler.

The signals SIGKILL and SIGSTOP cannot be caught or ignored.

RETURN VALUE

signal() returns the previous value of the signal handler, or SIG_ERR on error.

ERRORS

EINVAL
signum is invalid.

CONFORMING TO

C89, C99, POSIX.1-2001.

NOTES

The effects of signal() in a multi-threaded process are unspecified.

According to POSIX, the behavior of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or raise(3). Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.) Ignoring this signal might lead to an endless loop.

See sigaction(2) for details on what happens when SIGCHLD is set to SIG_IGN.

See signal(7) for a list of the async-signal-safe functions that can be safely called inside from inside a signal handler.

The use of sighandler_t is a GNU extension. Various versions of libc predefine this type; libc4 and libc5 define SignalHandler, glibc defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t.

Portability

The original Unix signal() would reset the handler to SIG_DFL, and System V (and the Linux kernel and libc4,5) does the same. On the other hand, BSD does not reset the handler, but blocks new instances of this signal from occurring during a call of the handler. The glibc2 library follows the BSD behavior.

If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal() is redefined as __bsd_signal() and signal() has the BSD semantics. This is not recommended.

If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or uses a separate sysv_signal(3) function, one obtains classical behavior. This is not recommended.

SEE ALSO

kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), bsd_signal(3), raise(3), siginterrupt(3), sigsetops(3), sigvec(3), sysv_signal(3), feature_test_macros(7), signal(7)

COLOPHON

This page is part of release 2.78 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/.