1SIGNAL(2)                  Linux Programmer's Manual                 SIGNAL(2)
2
3
4

NAME

6       signal - ANSI C signal handling
7

SYNOPSIS

9       #include <signal.h>
10
11       typedef void (*sighandler_t)(int);
12
13       sighandler_t signal(int signum, sighandler_t handler);
14

DESCRIPTION

16       The behavior of signal() varies across UNIX versions, and has also var‐
17       ied historically across different versions of Linux.   Avoid  its  use:
18       use sigaction(2) instead.  See Portability below.
19
20       signal() sets the disposition of the signal signum to handler, which is
21       either SIG_IGN, SIG_DFL, or the address of a  programmer-defined  func‐
22       tion (a "signal handler").
23
24       If  the signal signum is delivered to the process, then one of the fol‐
25       lowing happens:
26
27       *  If the disposition is set to SIG_IGN, then the signal is ignored.
28
29       *  If the disposition is set to SIG_DFL, then the default action  asso‐
30          ciated with the signal (see signal(7)) occurs.
31
32       *  If  the disposition is set to a function, then first either the dis‐
33          position is reset to SIG_DFL, or the signal is blocked  (see  Porta‐
34          bility  below), and then handler is called with argument signum.  If
35          invocation of the handler caused the signal to be blocked, then  the
36          signal is unblocked upon return from the handler.
37
38       The signals SIGKILL and SIGSTOP cannot be caught or ignored.
39

RETURN VALUE

41       signal()  returns  the previous value of the signal handler, or SIG_ERR
42       on error.  In the event of an error,  errno  is  set  to  indicate  the
43       cause.
44

ERRORS

46       EINVAL signum is invalid.
47

CONFORMING TO

49       POSIX.1-2001, POSIX.1-2008, C89, C99.
50

NOTES

52       The effects of signal() in a multithreaded process are unspecified.
53
54       According  to  POSIX,  the  behavior of a process is undefined after it
55       ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not  generated  by
56       kill(2)  or  raise(3).   Integer division by zero has undefined result.
57       On some architectures it will generate a SIGFPE signal.  (Also dividing
58       the  most  negative  integer by -1 may generate SIGFPE.)  Ignoring this
59       signal might lead to an endless loop.
60
61       See sigaction(2) for details  on  what  happens  when  the  disposition
62       SIGCHLD is set to SIG_IGN.
63
64       See signal-safety(7) for a list of the async-signal-safe functions that
65       can be safely called from inside a signal handler.
66
67       The use of sighandler_t is a GNU extension, exposed if  _GNU_SOURCE  is
68       defined;  glibc  also  defines  (the  BSD-derived) sig_t if _BSD_SOURCE
69       (glibc 2.19 and earlier) or _DEFAULT_SOURCE (glibc 2.19 and  later)  is
70       defined.   Without  use  of such a type, the declaration of signal() is
71       the somewhat harder to read:
72
73           void ( *signal(int signum, void (*handler)(int)) ) (int);
74
75   Portability
76       The only portable use of signal() is to set a signal's  disposition  to
77       SIG_DFL  or  SIG_IGN.  The semantics when using signal() to establish a
78       signal handler vary across systems (and POSIX.1 explicitly permits this
79       variation); do not use it for this purpose.
80
81       POSIX.1  solved  the portability mess by specifying sigaction(2), which
82       provides explicit control of the semantics when  a  signal  handler  is
83       invoked; use that interface instead of signal().
84
85       In the original UNIX systems, when a handler that was established using
86       signal() was invoked by the delivery of a signal,  the  disposition  of
87       the  signal  would  be  reset  to SIG_DFL, and the system did not block
88       delivery of further instances of the signal.   This  is  equivalent  to
89       calling sigaction(2) with the following flags:
90
91           sa.sa_flags = SA_RESETHAND | SA_NODEFER;
92
93       System V  also  provides  these  semantics  for signal().  This was bad
94       because the signal might be delivered again before the  handler  had  a
95       chance  to  reestablish  itself.   Furthermore, rapid deliveries of the
96       same signal could result in recursive invocations of the handler.
97
98       BSD improved on this situation,  but  unfortunately  also  changed  the
99       semantics  of  the existing signal() interface while doing so.  On BSD,
100       when a signal handler is invoked, the signal disposition is not  reset,
101       and  further  instances  of the signal are blocked from being delivered
102       while the handler is executing.  Furthermore, certain  blocking  system
103       calls  are  automatically  restarted if interrupted by a signal handler
104       (see signal(7)).  The BSD semantics are equivalent  to  calling  sigac‐
105       tion(2) with the following flags:
106
107           sa.sa_flags = SA_RESTART;
108
109       The situation on Linux is as follows:
110
111       * The kernel's signal() system call provides System V semantics.
112
113       * By  default, in glibc 2 and later, the signal() wrapper function does
114         not invoke the kernel system call.  Instead,  it  calls  sigaction(2)
115         using flags that supply BSD semantics.  This default behavior is pro‐
116         vided  as  long  as  a  suitable  feature  test  macro  is   defined:
117         _BSD_SOURCE  on  glibc  2.19  and earlier or _DEFAULT_SOURCE in glibc
118         2.19 and later.  (By default, these  macros  are  defined;  see  fea‐
119         ture_test_macros(7)  for  details.)   If such a feature test macro is
120         not defined, then signal() provides System V semantics.
121

SEE ALSO

123       kill(1), alarm(2), kill(2), pause(2), sigaction(2),  signalfd(2),  sig‐
124       pending(2),  sigprocmask(2),  sigsuspend(2),  bsd_signal(3), killpg(3),
125       raise(3),  siginterrupt(3),   sigqueue(3),   sigsetops(3),   sigvec(3),
126       sysv_signal(3), signal(7)
127

COLOPHON

129       This  page  is  part of release 4.16 of the Linux man-pages project.  A
130       description of the project, information about reporting bugs,  and  the
131       latest     version     of     this    page,    can    be    found    at
132       https://www.kernel.org/doc/man-pages/.
133
134
135
136Linux                             2017-09-15                         SIGNAL(2)
Impressum