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

CONFORMING TO

583       POSIX.1, except as noted.
584

NOTES

586       For a discussion of async-signal-safe functions, see signal-safety(7).
587
588       The  /proc/[pid]/task/[tid]/status  file  contains  various fields that
589       show the signals that a thread is blocking (SigBlk), catching (SigCgt),
590       or  ignoring  (SigIgn).  (The set of signals that are caught or ignored
591       will be the same across all threads in a process.)  Other  fields  show
592       the  set of pending signals that are directed to the thread (SigPnd) as
593       well as the set of pending signals that are directed to the process  as
594       a  whole (ShdPnd).  The corresponding fields in /proc/[pid]/status show
595       the information for the main thread.  See proc(5) for further details.
596

BUGS

598       There are six signals that can be delivered as a consequence of a hard‐
599       ware  exception:  SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP.
600       Which of these signals is delivered, for any given hardware  exception,
601       is not documented and does not always make sense.
602
603       For  example,  an invalid memory access that causes delivery of SIGSEGV
604       on one CPU architecture may cause delivery of SIGBUS on another  archi‐
605       tecture, or vice versa.
606
607       For another example, using the x86 int instruction with a forbidden ar‐
608       gument (any number other than 3 or 128)  causes  delivery  of  SIGSEGV,
609       even  though  SIGILL  would make more sense, because of how the CPU re‐
610       ports the forbidden operation to the kernel.
611

SEE ALSO

613       kill(1),   clone(2),   getrlimit(2),   kill(2),   pidfd_send_signal(2),
614       restart_syscall(2),   rt_sigqueueinfo(2),  setitimer(2),  setrlimit(2),
615       sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sig‐
616       pending(2),   sigprocmask(2),   sigreturn(2),  sigsuspend(2),  sigwait‐
617       info(2),    abort(3),     bsd_signal(3),     killpg(3),     longjmp(3),
618       pthread_sigqueue(3),  raise(3),  sigqueue(3),  sigset(3), sigsetops(3),
619       sigvec(3), sigwait(3),  strsignal(3),  swapcontext(3),  sysv_signal(3),
620       core(5), proc(5), nptl(7), pthreads(7), sigevent(7)
621

COLOPHON

623       This  page  is  part of release 5.13 of the Linux man-pages project.  A
624       description of the project, information about reporting bugs,  and  the
625       latest     version     of     this    page,    can    be    found    at
626       https://www.kernel.org/doc/man-pages/.
627
628
629
630Linux                             2021-03-22                         SIGNAL(7)
Impressum