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

NAME

6       signal - overview of signals
7

DESCRIPTION

9       Linux  supports both POSIX reliable signals (hereinafter "standard sig‐
10       nals") and POSIX real-time signals.
11
12   Signal dispositions
13       Each signal has a current disposition, which determines how the process
14       behaves when it is delivered the signal.
15
16       The  entries  in  the  "Action"  column of the tables below specify the
17       default disposition for each signal, as follows:
18
19       Term   Default action is to terminate the process.
20
21       Ign    Default action is to ignore the signal.
22
23       Core   Default action is to terminate the process and  dump  core  (see
24              core(5)).
25
26       Stop   Default action is to stop the process.
27
28       Cont   Default  action  is  to  continue the process if it is currently
29              stopped.
30
31       A process can change the disposition of a signal using sigaction(2)  or
32       signal(2).   (The  latter  is  less portable when establishing a signal
33       handler; see signal(2) for  details.)   Using  these  system  calls,  a
34       process  can  elect one of the following behaviors to occur on delivery
35       of the signal: perform the default action; ignore the signal; or  catch
36       the signal with a signal handler, a programmer-defined function that is
37       automatically invoked when the signal is delivered.  (By  default,  the
38       signal  handler is invoked on the normal process stack.  It is possible
39       to arrange that the signal handler uses an alternate stack; see sigalt‐
40       stack(2)  for  a discussion of how to do this and when it might be use‐
41       ful.)
42
43       The signal disposition is a per-process attribute: in  a  multithreaded
44       application, the disposition of a particular signal is the same for all
45       threads.
46
47       A child created via fork(2) inherits a copy of its parent's signal dis‐
48       positions.   During  an  execve(2), the dispositions of handled signals
49       are reset to the default; the dispositions of ignored signals are  left
50       unchanged.
51
52   Sending a signal
53       The  following  system  calls and library functions allow the caller to
54       send a signal:
55
56       raise(3)        Sends a signal to the calling thread.
57
58       kill(2)         Sends a signal to a specified process, to  all  members
59                       of  a  specified  process group, or to all processes on
60                       the system.
61
62       killpg(3)       Sends a signal to all of the  members  of  a  specified
63                       process group.
64
65       pthread_kill(3) Sends  a signal to a specified POSIX thread in the same
66                       process as the caller.
67
68       tgkill(2)       Sends a signal to a specified thread within a  specific
69                       process.   (This  is  the system call used to implement
70                       pthread_kill(3).)
71
72       sigqueue(3)     Sends a real-time signal with accompanying  data  to  a
73                       specified process.
74
75   Waiting for a signal to be caught
76       The  following system calls suspend execution of the calling process or
77       thread until a signal is caught (or an unhandled signal terminates  the
78       process):
79
80       pause(2)        Suspends execution until any signal is caught.
81
82       sigsuspend(2)   Temporarily  changes  the  signal  mask (see below) and
83                       suspends execution until one of the unmasked signals is
84                       caught.
85
86   Synchronously accepting a signal
87       Rather  than  asynchronously catching a signal via a signal handler, it
88       is possible to synchronously accept the signal, that is, to block  exe‐
89       cution until the signal is delivered, at which point the kernel returns
90       information about the signal to the caller.  There are two general ways
91       to do this:
92
93       * sigwaitinfo(2),  sigtimedwait(2),  and  sigwait(3)  suspend execution
94         until one of the signals in a specified set is  delivered.   Each  of
95         these calls returns information about the delivered signal.
96
97       * signalfd(2) returns a file descriptor that can be used to read infor‐
98         mation about signals that are delivered to the caller.  Each  read(2)
99         from  this file descriptor blocks until one of the signals in the set
100         specified in the signalfd(2) call is delivered to  the  caller.   The
101         buffer  returned  by read(2) contains a structure describing the sig‐
102         nal.
103
104   Signal mask and pending signals
105       A signal may be blocked, which means that  it  will  not  be  delivered
106       until it is later unblocked.  Between the time when it is generated and
107       when it is delivered a signal is said to be pending.
108
109       Each thread in a process has an independent signal  mask,  which  indi‐
110       cates  the  set  of  signals  that the thread is currently blocking.  A
111       thread can manipulate its signal mask using pthread_sigmask(3).   In  a
112       traditional  single-threaded application, sigprocmask(2) can be used to
113       manipulate the signal mask.
114
115       A child created via fork(2) inherits a  copy  of  its  parent's  signal
116       mask; the signal mask is preserved across execve(2).
117
118       A  signal  may be generated (and thus pending) for a process as a whole
119       (e.g., when sent using kill(2)) or for a specific thread (e.g., certain
120       signals, such as SIGSEGV and SIGFPE, generated as a consequence of exe‐
121       cuting a specific machine-language instruction are thread directed,  as
122       are  signals  targeted  at a specific thread using pthread_kill(3)).  A
123       process-directed signal may be delivered to any one of the threads that
124       does  not  currently  have the signal blocked.  If more than one of the
125       threads has the signal unblocked, then the kernel chooses an  arbitrary
126       thread to which to deliver the signal.
127
128       A  thread  can  obtain the set of signals that it currently has pending
129       using sigpending(2).  This set will consist of the union of the set  of
130       pending process-directed signals and the set of signals pending for the
131       calling thread.
132
133       A child created via fork(2) initially has an empty pending signal  set;
134       the pending signal set is preserved across an execve(2).
135
136   Standard signals
137       Linux  supports the standard signals listed below.  Several signal num‐
138       bers are architecture-dependent, as indicated in  the  "Value"  column.
139       (Where three values are given, the first one is usually valid for alpha
140       and sparc, the middle one for x86, arm, and most  other  architectures,
141       and  the  last one for mips.  (Values for parisc are not shown; see the
142       Linux kernel source for signal numbering on that architecture.)  A dash
143       (-) denotes that a signal is absent on the corresponding architecture.
144
145       First the signals described in the original POSIX.1-1990 standard.
146
147       Signal     Value     Action   Comment
148       ──────────────────────────────────────────────────────────────────────
149       SIGHUP        1       Term    Hangup detected on controlling terminal
150                                     or death of controlling process
151       SIGINT        2       Term    Interrupt from keyboard
152       SIGQUIT       3       Core    Quit from keyboard
153       SIGILL        4       Core    Illegal Instruction
154       SIGABRT       6       Core    Abort signal from abort(3)
155       SIGFPE        8       Core    Floating-point exception
156       SIGKILL       9       Term    Kill signal
157       SIGSEGV      11       Core    Invalid memory reference
158       SIGPIPE      13       Term    Broken pipe: write to pipe with no
159                                     readers; see pipe(7)
160       SIGALRM      14       Term    Timer signal from alarm(2)
161       SIGTERM      15       Term    Termination signal
162       SIGUSR1   30,10,16    Term    User-defined signal 1
163       SIGUSR2   31,12,17    Term    User-defined signal 2
164       SIGCHLD   20,17,18    Ign     Child stopped or terminated
165       SIGCONT   19,18,25    Cont    Continue if stopped
166       SIGSTOP   17,19,23    Stop    Stop process
167       SIGTSTP   18,20,24    Stop    Stop typed at terminal
168       SIGTTIN   21,21,26    Stop    Terminal input for background process
169       SIGTTOU   22,22,27    Stop    Terminal output for background process
170
171       The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
172
173       Next  the  signals  not  in  the POSIX.1-1990 standard but described in
174       SUSv2 and POSIX.1-2001.
175
176       Signal       Value     Action   Comment
177       ────────────────────────────────────────────────────────────────────
178       SIGBUS      10,7,10     Core    Bus error (bad memory access)
179       SIGPOLL                 Term    Pollable event (Sys V).
180                                       Synonym for SIGIO
181       SIGPROF     27,27,29    Term    Profiling timer expired
182       SIGSYS      12,31,12    Core    Bad system call (SVr4);
183                                       see also seccomp(2)
184       SIGTRAP        5        Core    Trace/breakpoint trap
185       SIGURG      16,23,21    Ign     Urgent condition on socket (4.2BSD)
186       SIGVTALRM   26,26,28    Term    Virtual alarm clock (4.2BSD)
187       SIGXCPU     24,24,30    Core    CPU time limit exceeded (4.2BSD);
188                                       see setrlimit(2)
189       SIGXFSZ     25,25,31    Core    File size limit exceeded (4.2BSD);
190                                       see setrlimit(2)
191
192       Up to and including Linux 2.2, the default behavior for  SIGSYS,  SIGX‐
193       CPU,  SIGXFSZ,  and (on architectures other than SPARC and MIPS) SIGBUS
194       was to terminate the process (without a core  dump).   (On  some  other
195       UNIX systems the default action for SIGXCPU and SIGXFSZ is to terminate
196       the  process  without  a  core  dump.)   Linux  2.4  conforms  to   the
197       POSIX.1-2001  requirements  for  these signals, terminating the process
198       with a core dump.
199
200       Next various other signals.
201
202       Signal       Value     Action   Comment
203       ────────────────────────────────────────────────────────────────────
204       SIGIOT         6        Core    IOT trap. A synonym for SIGABRT
205       SIGEMT       7,-,7      Term    Emulator trap
206       SIGSTKFLT    -,16,-     Term    Stack fault on coprocessor (unused)
207       SIGIO       23,29,22    Term    I/O now possible (4.2BSD)
208       SIGCLD       -,-,18     Ign     A synonym for SIGCHLD
209       SIGPWR      29,30,19    Term    Power failure (System V)
210       SIGINFO      29,-,-             A synonym for SIGPWR
211       SIGLOST      -,-,-      Term    File lock lost (unused)
212       SIGWINCH    28,28,20    Ign     Window resize signal (4.3BSD, Sun)
213       SIGUNUSED    -,31,-     Core    Synonymous with SIGSYS
214
215       (Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)
216
217       SIGEMT is not specified in POSIX.1-2001, but  nevertheless  appears  on
218       most  other UNIX systems, where its default action is typically to ter‐
219       minate the process with a core dump.
220
221       SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by
222       default on those other UNIX systems where it appears.
223
224       SIGIO (which is not specified in POSIX.1-2001) is ignored by default on
225       several other UNIX systems.
226
227       Where defined, SIGUNUSED is synonymous with SIGSYS  on  most  architec‐
228       tures.   Since glibc 2.26, SIGUNUSED is no longer defined on any archi‐
229       tecture.
230
231   Real-time signals
232       Starting with version 2.2, Linux supports real-time signals  as  origi‐
233       nally defined in the POSIX.1b real-time extensions (and now included in
234       POSIX.1-2001).  The range of supported real-time signals is defined  by
235       the macros SIGRTMIN and SIGRTMAX.  POSIX.1-2001 requires that an imple‐
236       mentation support at least _POSIX_RTSIG_MAX (8) real-time signals.
237
238       The Linux kernel supports a range of 33  different  real-time  signals,
239       numbered  32  to  64.   However, the glibc POSIX threads implementation
240       internally uses two (for NPTL) or three  (for  LinuxThreads)  real-time
241       signals  (see  pthreads(7)), and adjusts the value of SIGRTMIN suitably
242       (to 34 or 35).  Because the range of available real-time signals varies
243       according to the glibc threading implementation (and this variation can
244       occur at run time according to the available  kernel  and  glibc),  and
245       indeed  the range of real-time signals varies across UNIX systems, pro‐
246       grams should never refer to real-time signals using hard-coded numbers,
247       but instead should always refer to real-time signals using the notation
248       SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does
249       not exceed SIGRTMAX.
250
251       Unlike standard signals, real-time signals have no predefined meanings:
252       the entire set of real-time signals can be used for application-defined
253       purposes.
254
255       The  default  action  for an unhandled real-time signal is to terminate
256       the receiving process.
257
258       Real-time signals are distinguished by the following:
259
260       1.  Multiple instances of real-time signals can  be  queued.   By  con‐
261           trast,  if  multiple  instances  of a standard signal are delivered
262           while that signal is currently blocked, then only one  instance  is
263           queued.
264
265       2.  If  the  signal  is  sent  using sigqueue(3), an accompanying value
266           (either an integer or a pointer) can be sent with the  signal.   If
267           the  receiving  process establishes a handler for this signal using
268           the SA_SIGINFO flag to sigaction(2), then it can obtain  this  data
269           via  the  si_value  field  of the siginfo_t structure passed as the
270           second argument to the handler.  Furthermore, the si_pid and si_uid
271           fields  of  this  structure  can be used to obtain the PID and real
272           user ID of the process sending the signal.
273
274       3.  Real-time signals are delivered in a  guaranteed  order.   Multiple
275           real-time  signals of the same type are delivered in the order they
276           were sent.  If different real-time signals are sent to  a  process,
277           they  are  delivered  starting  with  the  lowest-numbered  signal.
278           (I.e., low-numbered signals have highest priority.)   By  contrast,
279           if  multiple  standard signals are pending for a process, the order
280           in which they are delivered is unspecified.
281
282       If both standard and real-time signals are pending for a process, POSIX
283       leaves it unspecified which is delivered first.  Linux, like many other
284       implementations, gives priority to standard signals in this case.
285
286       According  to  POSIX,  an  implementation  should   permit   at   least
287       _POSIX_SIGQUEUE_MAX  (32)  real-time signals to be queued to a process.
288       However, Linux does things differently.  In kernels up to and including
289       2.6.7,  Linux imposes a system-wide limit on the number of queued real-
290       time signals for all processes.  This limit can  be  viewed  and  (with
291       privilege)  changed via the /proc/sys/kernel/rtsig-max file.  A related
292       file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-
293       time  signals are currently queued.  In Linux 2.6.8, these /proc inter‐
294       faces were replaced by  the  RLIMIT_SIGPENDING  resource  limit,  which
295       specifies  a  per-user  limit  for queued signals; see setrlimit(2) for
296       further details.
297
298       The addition of real-time signals required the widening of  the  signal
299       set  structure  (sigset_t)  from  32 to 64 bits.  Consequently, various
300       system calls were superseded by new system  calls  that  supported  the
301       larger signal sets.  The old and new system calls are as follows:
302
303       Linux 2.0 and earlier   Linux 2.2 and later
304       sigaction(2)            rt_sigaction(2)
305       sigpending(2)           rt_sigpending(2)
306       sigprocmask(2)          rt_sigprocmask(2)
307       sigreturn(2)            rt_sigreturn(2)
308       sigsuspend(2)           rt_sigsuspend(2)
309       sigtimedwait(2)         rt_sigtimedwait(2)
310
311   Interruption of system calls and library functions by signal handlers
312       If  a signal handler is invoked while a system call or library function
313       call is blocked, then either:
314
315       * the call is automatically restarted after the signal handler returns;
316         or
317
318       * the call fails with the error EINTR.
319
320       Which  of  these  two  behaviors  occurs  depends  on the interface and
321       whether or not the signal handler was established using the  SA_RESTART
322       flag  (see sigaction(2)).  The details vary across UNIX systems; below,
323       the details for Linux.
324
325       If a blocked call to one of the following interfaces is interrupted  by
326       a  signal  handler,  then the call is automatically restarted after the
327       signal handler returns if the SA_RESTART flag was used;  otherwise  the
328       call fails with the error EINTR:
329
330       * read(2),  readv(2), write(2), writev(2), and ioctl(2) calls on "slow"
331         devices.  A "slow" device is one where the I/O call may block for  an
332         indefinite time, for example, a terminal, pipe, or socket.  If an I/O
333         call on a slow device has already transferred some data by  the  time
334         it  is  interrupted  by a signal handler, then the call will return a
335         success status (normally, the number  of  bytes  transferred).   Note
336         that  a  (local)  disk is not a slow device according to this defini‐
337         tion; I/O operations on disk devices are not interrupted by signals.
338
339       * open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
340
341       * wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
342
343       * Socket  interfaces:  accept(2),  connect(2),  recv(2),   recvfrom(2),
344         recvmmsg(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a
345         timeout has been set on the socket (see below).
346
347       * File locking interfaces: flock(2) and the F_SETLKW  and  F_OFD_SETLKW
348         operations of fcntl(2)
349
350       * POSIX  message  queue  interfaces: mq_receive(3), mq_timedreceive(3),
351         mq_send(3), and mq_timedsend(3).
352
353       * futex(2) FUTEX_WAIT (since Linux 2.6.22;  beforehand,  always  failed
354         with EINTR).
355
356       * getrandom(2).
357
358       * pthread_mutex_lock(3), pthread_cond_wait(3), and related APIs.
359
360       * futex(2) FUTEX_WAIT_BITSET.
361
362       * POSIX  semaphore  interfaces: sem_wait(3) and sem_timedwait(3) (since
363         Linux 2.6.22; beforehand, always failed with EINTR).
364
365       * read(2) from an inotify(7) file descriptor (since Linux 3.8;  before‐
366         hand, always failed with EINTR).
367
368       The following interfaces are never restarted after being interrupted by
369       a signal handler, regardless of the use of SA_RESTART; they always fail
370       with the error EINTR when interrupted by a signal handler:
371
372       * "Input"  socket interfaces, when a timeout (SO_RCVTIMEO) has been set
373         on the socket using setsockopt(2): accept(2),  recv(2),  recvfrom(2),
374         recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).
375
376       * "Output" socket interfaces, when a timeout (SO_RCVTIMEO) has been set
377         on the socket using setsockopt(2):  connect(2),  send(2),  sendto(2),
378         and sendmsg(2).
379
380       * Interfaces  used  to  wait for signals: pause(2), sigsuspend(2), sig‐
381         timedwait(2), and sigwaitinfo(2).
382
383       * File    descriptor    multiplexing     interfaces:     epoll_wait(2),
384         epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).
385
386       * System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and semtime‐
387         dop(2).
388
389       * Sleep interfaces: clock_nanosleep(2), nanosleep(2), and usleep(3).
390
391       * io_getevents(2).
392
393       The sleep(3) function is also never restarted if interrupted by a  han‐
394       dler,  but  gives  a success return: the number of seconds remaining to
395       sleep.
396
397   Interruption of system calls and library functions by stop signals
398       On Linux, even in the absence  of  signal  handlers,  certain  blocking
399       interfaces  can  fail with the error EINTR after the process is stopped
400       by one of the stop signals and then resumed via SIGCONT.  This behavior
401       is not sanctioned by POSIX.1, and doesn't occur on other systems.
402
403       The Linux interfaces that display this behavior are:
404
405       * "Input"  socket interfaces, when a timeout (SO_RCVTIMEO) has been set
406         on the socket using setsockopt(2): accept(2),  recv(2),  recvfrom(2),
407         recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).
408
409       * "Output" socket interfaces, when a timeout (SO_RCVTIMEO) has been set
410         on the socket using setsockopt(2):  connect(2),  send(2),  sendto(2),
411         and sendmsg(2), if a send timeout (SO_SNDTIMEO) has been set.
412
413       * epoll_wait(2), epoll_pwait(2).
414
415       * semop(2), semtimedop(2).
416
417       * sigtimedwait(2), sigwaitinfo(2).
418
419       * Linux 3.7 and earlier: read(2) from an inotify(7) file descriptor
420
421       * Linux  2.6.21  and  earlier:  futex(2)  FUTEX_WAIT, sem_timedwait(3),
422         sem_wait(3).
423
424       * Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2).
425
426       * Linux 2.4 and earlier: nanosleep(2).
427

CONFORMING TO

429       POSIX.1, except as noted.
430

NOTES

432       For a discussion of async-signal-safe functions, see signal-safety(7).
433

SEE ALSO

435       kill(1), getrlimit(2), kill(2), restart_syscall(2), rt_sigqueueinfo(2),
436       setitimer(2),  setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2),
437       signal(2), signalfd(2),  sigpending(2),  sigprocmask(2),  sigreturn(2),
438       sigsuspend(2),   sigwaitinfo(2),  abort(3),  bsd_signal(3),  killpg(3),
439       longjmp(3),  pthread_sigqueue(3),  raise(3),  sigqueue(3),   sigset(3),
440       sigsetops(3),   sigvec(3),  sigwait(3),  strsignal(3),  sysv_signal(3),
441       core(5), proc(5), nptl(7), pthreads(7), sigevent(7)
442

COLOPHON

444       This page is part of release 4.16 of the Linux  man-pages  project.   A
445       description  of  the project, information about reporting bugs, and the
446       latest    version    of    this    page,    can     be     found     at
447       https://www.kernel.org/doc/man-pages/.
448
449
450
451Linux                             2017-09-15                         SIGNAL(7)
Impressum