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

CONFORMING TO

490       POSIX.1, except as noted.
491

NOTES

493       For a discussion of async-signal-safe functions, see signal-safety(7).
494
495       The /proc/[pid]/task/[tid]/status file  contains  various  fields  that
496       show the signals that a thread is blocking (SigBlk), catching (SigCgt),
497       or ignoring (SigIgn).  (The set of signals that are caught  or  ignored
498       will  be  the same across all threads in a process.)  Other fields show
499       the set of pending signals that are directed to the thread (SigPnd)  as
500       well  as the set of pending signals that are directed to the process as
501       a whole (ShdPnd).  The corresponding fields in /proc/[pid]/status  show
502       the information for the main thread.  See proc(5) for further details.
503

SEE ALSO

505       kill(1),    clone(2),    getrlimit(2),   kill(2),   restart_syscall(2),
506       rt_sigqueueinfo(2), pidfd_send_signal(2),  setitimer(2),  setrlimit(2),
507       sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sig‐
508       pending(2),  sigprocmask(2),  sigreturn(2),   sigsuspend(2),   sigwait‐
509       info(2),     abort(3),     bsd_signal(3),     killpg(3),    longjmp(3),
510       pthread_sigqueue(3), raise(3),  sigqueue(3),  sigset(3),  sigsetops(3),
511       sigvec(3),  sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5),
512       nptl(7), pthreads(7), sigevent(7)
513

COLOPHON

515       This page is part of release 5.04 of the Linux  man-pages  project.   A
516       description  of  the project, information about reporting bugs, and the
517       latest    version    of    this    page,    can     be     found     at
518       https://www.kernel.org/doc/man-pages/.
519
520
521
522Linux                             2019-08-02                         SIGNAL(7)
Impressum