| blob | bc315560558270c637ec5c96fe6782c9828a8394 |
1 .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de)
2 .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk <mtk.manpages@gmail.com>
3 .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
4 .\" <mtk.manpages@gmail.com>
5 .\"
6 .\" %%%LICENSE_START(VERBATIM)
7 .\" Permission is granted to make and distribute verbatim copies of this
8 .\" manual provided the copyright notice and this permission notice are
9 .\" preserved on all copies.
10 .\"
11 .\" Permission is granted to copy and distribute modified versions of this
12 .\" manual under the conditions for verbatim copying, provided that the
13 .\" entire resulting derived work is distributed under the terms of a
14 .\" permission notice identical to this one.
15 .\"
16 .\" Since the Linux kernel and libraries are constantly changing, this
17 .\" manual page may be incorrect or out-of-date. The author(s) assume no
18 .\" responsibility for errors or omissions, or for damages resulting from
19 .\" the use of the information contained herein. The author(s) may not
20 .\" have taken the same level of care in the production of this manual,
21 .\" which is licensed free of charge, as they might when working
22 .\" professionally.
23 .\"
24 .\" Formatted or processed versions of this manual, if unaccompanied by
25 .\" the source, must acknowledge the copyright and authors of this work.
26 .\" %%%LICENSE_END
27 .\"
28 .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu)
29 .\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl)
30 .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl)
31 .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl)
32 .\" Modified 10 Apr 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
33 .\" Modified 7 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
34 .\" Added information on real-time signals
35 .\" Modified 13 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
36 .\" Noted that SIGSTKFLT is in fact unused
37 .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING
38 .\" 2006-04-24, mtk, Added text on changing signal dispositions,
39 .\" signal mask, and pending signals.
40 .\" 2008-07-04, mtk:
41 .\" Added section on system call restarting (SA_RESTART)
42 .\" Added section on stop/cont signals interrupting syscalls.
43 .\" 2008-10-05, mtk: various additions
44 .\"
45 .TH SIGNAL 7 2021-03-22 "Linux" "Linux Programmer's Manual"
46 .SH NAME
47 signal \- overview of signals
48 .SH DESCRIPTION
49 Linux supports both POSIX reliable signals (hereinafter
50 "standard signals") and POSIX real-time signals.
51 .SS Signal dispositions
52 Each signal has a current
53 .IR disposition ,
54 which determines how the process behaves when it is delivered
55 the signal.
56 .PP
57 The entries in the "Action" column of the table below specify
58 the default disposition for each signal, as follows:
59 .IP Term
60 Default action is to terminate the process.
61 .IP Ign
62 Default action is to ignore the signal.
63 .IP Core
64 Default action is to terminate the process and dump core (see
65 .BR core (5)).
66 .IP Stop
67 Default action is to stop the process.
68 .IP Cont
69 Default action is to continue the process if it is currently stopped.
70 .PP
71 A process can change the disposition of a signal using
72 .BR sigaction (2)
73 or
74 .BR signal (2).
75 (The latter is less portable when establishing a signal handler;
76 see
77 .BR signal (2)
78 for details.)
79 Using these system calls, a process can elect one of the
80 following behaviors to occur on delivery of the signal:
81 perform the default action; ignore the signal;
82 or catch the signal with a
83 .IR "signal handler" ,
84 a programmer-defined function that is automatically invoked
85 when the signal is delivered.
86 .PP
87 By default, a signal handler is invoked on the
88 normal process stack.
89 It is possible to arrange that the signal handler
90 uses an alternate stack; see
91 .BR sigaltstack (2)
92 for a discussion of how to do this and when it might be useful.
93 .PP
94 The signal disposition is a per-process attribute:
95 in a multithreaded application, the disposition of a
96 particular signal is the same for all threads.
97 .PP
98 A child created via
99 .BR fork (2)
100 inherits a copy of its parent's signal dispositions.
101 During an
102 .BR execve (2),
103 the dispositions of handled signals are reset to the default;
104 the dispositions of ignored signals are left unchanged.
105 .SS Sending a signal
106 The following system calls and library functions allow
107 the caller to send a signal:
108 .TP
109 .BR raise (3)
110 Sends a signal to the calling thread.
111 .TP
112 .BR kill (2)
113 Sends a signal to a specified process,
114 to all members of a specified process group,
115 or to all processes on the system.
116 .TP
117 .BR pidfd_send_signal (2)
118 Sends a signal to a process identified by a PID file descriptor.
119 .TP
120 .BR killpg (3)
121 Sends a signal to all of the members of a specified process group.
122 .TP
123 .BR pthread_kill (3)
124 Sends a signal to a specified POSIX thread in the same process as
125 the caller.
126 .TP
127 .BR tgkill (2)
128 Sends a signal to a specified thread within a specific process.
129 (This is the system call used to implement
130 .BR pthread_kill (3).)
131 .TP
132 .BR sigqueue (3)
133 Sends a real-time signal with accompanying data to a specified process.
134 .SS Waiting for a signal to be caught
135 The following system calls suspend execution of the calling
136 thread until a signal is caught
137 (or an unhandled signal terminates the process):
138 .TP
139 .BR pause (2)
140 Suspends execution until any signal is caught.
141 .TP
142 .BR sigsuspend (2)
143 Temporarily changes the signal mask (see below) and suspends
144 execution until one of the unmasked signals is caught.
145 .\"
146 .SS Synchronously accepting a signal
147 Rather than asynchronously catching a signal via a signal handler,
148 it is possible to synchronously accept the signal, that is,
149 to block execution until the signal is delivered,
150 at which point the kernel returns information about the
151 signal to the caller.
152 There are two general ways to do this:
153 .IP * 2
154 .BR sigwaitinfo (2),
155 .BR sigtimedwait (2),
156 and
157 .BR sigwait (3)
158 suspend execution until one of the signals in a specified
159 set is delivered.
160 Each of these calls returns information about the delivered signal.
161 .IP *
162 .BR signalfd (2)
163 returns a file descriptor that can be used to read information
164 about signals that are delivered to the caller.
165 Each
166 .BR read (2)
167 from this file descriptor blocks until one of the signals
168 in the set specified in the
169 .BR signalfd (2)
170 call is delivered to the caller.
171 The buffer returned by
172 .BR read (2)
173 contains a structure describing the signal.
174 .SS Signal mask and pending signals
175 A signal may be
176 .IR blocked ,
177 which means that it will not be delivered until it is later unblocked.
178 Between the time when it is generated and when it is delivered
179 a signal is said to be
180 .IR pending .
181 .PP
182 Each thread in a process has an independent
183 .IR "signal mask" ,
184 which indicates the set of signals that the thread is currently blocking.
185 A thread can manipulate its signal mask using
186 .BR pthread_sigmask (3).
187 In a traditional single-threaded application,
188 .BR sigprocmask (2)
189 can be used to manipulate the signal mask.
190 .PP
191 A child created via
192 .BR fork (2)
193 inherits a copy of its parent's signal mask;
194 the signal mask is preserved across
195 .BR execve (2).
196 .PP
197 A signal may be process-directed or thread-directed.
198 A process-directed signal is one that is targeted at (and thus pending for)
199 the process as a whole.
200 A signal may be process-directed
201 because it was generated by the kernel for reasons
202 other than a hardware exception, or because it was sent using
203 .BR kill (2)
204 or
205 .BR sigqueue (3).
206 A thread-directed signal is one that is targeted at a specific thread.
207 A signal may be thread-directed because it was generated as a consequence
208 of executing a specific machine-language instruction
209 that triggered a hardware exception (e.g.,
210 .B SIGSEGV
211 for an invalid memory access, or
212 .B SIGFPE
213 for a math error), or because it was
214 targeted at a specific thread using
215 interfaces such as
216 .BR tgkill (2)
217 or
218 .BR pthread_kill (3).
219 .PP
220 A process-directed signal may be delivered to any one of the
221 threads that does not currently have the signal blocked.
222 .\" Joseph C. Sible notes:
223 .\" On Linux, if the main thread has the signal unblocked, then the kernel
224 .\" will always deliver the signal there, citing this kernel code
225 .\"
226 .\" Per this comment in kernel/signal.c since time immemorial:
227 .\"
228 .\" /*
229 .\" * Now find a thread we can wake up to take the signal off the queue.
230 .\" *
231 .\" * If the main thread wants the signal, it gets first crack.
232 .\" * Probably the least surprising to the average bear.
233 .\" */
234 .\"
235 .\" But this does not mean the signal will be delivered only in the
236 .\" main thread, since if a handler is already executing in the main thread
237 .\" (and thus the signal is blocked in that thread), then a further
238 .\" might be delivered in a different thread.
239 .\"
240 If more than one of the threads has the signal unblocked, then the
241 kernel chooses an arbitrary thread to which to deliver the signal.
242 .PP
243 A thread can obtain the set of signals that it currently has pending
244 using
245 .BR sigpending (2).
246 This set will consist of the union of the set of pending
247 process-directed signals and the set of signals pending for
248 the calling thread.
249 .PP
250 A child created via
251 .BR fork (2)
252 initially has an empty pending signal set;
253 the pending signal set is preserved across an
254 .BR execve (2).
255 .\"
256 .SS Execution of signal handlers
257 Whenever there is a transition from kernel-mode to user-mode execution
258 (e.g., on return from a system call or scheduling of a thread onto the CPU),
259 the kernel checks whether there is a pending unblocked signal
260 for which the process has established a signal handler.
261 If there is such a pending signal, the following steps occur:
262 .IP 1. 3
263 The kernel performs the necessary preparatory steps for execution of
264 the signal handler:
265 .RS
266 .IP a) 3
267 The signal is removed from the set of pending signals.
268 .IP b)
269 If the signal handler was installed by a call to
270 .BR sigaction (2)
271 that specified the
272 .BR SA_ONSTACK
273 flag and the thread has defined an alternate signal stack (using
274 .BR sigaltstack (2)),
275 then that stack is installed.
276 .IP c)
277 Various pieces of signal-related context are saved
278 into a special frame that is created on the stack.
279 The saved information includes:
280 .RS
281 .IP + 2
282 the program counter register
283 (i.e., the address of the next instruction in the main program that
284 should be executed when the signal handler returns);
285 .IP +
286 architecture-specific register state required for resuming the
287 interrupted program;
288 .IP +
289 the thread's current signal mask;
290 .IP +
291 the thread's alternate signal stack settings.
292 .RE
293 .IP
294 (If the signal handler was installed using the
295 .BR sigaction (2)
296 .B SA_SIGINFO
297 flag, then the above information is accessible via the
298 .I ucontext_t
299 object that is pointed to by the third argument of the signal handler.)
300 .IP d)
301 Any signals specified in
302 .I act\->sa_mask
303 when registering the handler with
304 .BR sigprocmask (2)
305 are added to the thread's signal mask.
306 The signal being delivered is also
307 added to the signal mask, unless
308 .B SA_NODEFER
309 was specified when registering the handler.
310 These signals are thus blocked while the handler executes.
311 .RE
312 .IP 2.
313 The kernel constructs a frame for the signal handler on the stack.
314 The kernel sets the program counter for the thread to point to the first
315 instruction of the signal handler function,
316 and configures the return address for that function to point to a piece
317 of user-space code known as the signal trampoline (described in
318 .BR sigreturn (2)).
319 .IP 3.
320 The kernel passes control back to user-space, where execution
321 commences at the start of the signal handler function.
322 .IP 4.
323 When the signal handler returns, control passes to the signal trampoline code.
324 .IP 5.
325 The signal trampoline calls
326 .BR sigreturn (2),
327 a system call that uses the information in the stack frame created in step 1
328 to restore the thread to its state before the signal handler was
329 called.
330 The thread's signal mask and alternate signal stack settings
331 are restored as part of this procedure.
332 Upon completion of the call to
333 .BR sigreturn (2),
334 the kernel transfers control back to user space,
335 and the thread recommences execution at the point where it was
336 interrupted by the signal handler.
337 .PP
338 Note that if the signal handler does not return
339 (e.g., control is transferred out of the handler using
340 .BR siglongjmp (3),
341 or the handler executes a new program with
342 .BR execve (2)),
343 then the final step is not performed.
344 In particular, in such scenarios it is the programmer's responsibility
345 to restore the state of the signal mask (using
346 .BR sigprocmask (2)),
347 if it is desired to unblock the signals that were blocked on entry
348 to the signal handler.
349 (Note that
350 .BR siglongjmp (3)
351 may or may not restore the signal mask, depending on the
352 .I savesigs
353 value that was specified in the corresponding call to
354 .BR sigsetjmp (3).)
355 .PP
356 From the kernel's point of view,
357 execution of the signal handler code is exactly the same as the execution
358 of any other user-space code.
359 That is to say, the kernel does not record any special state information
360 indicating that the thread is currently executing inside a signal handler.
361 All necessary state information is maintained in user-space registers
362 and the user-space stack.
363 The depth to which nested signal handlers may be invoked is thus
364 limited only by the user-space stack (and sensible software design!).
365 .\"
366 .SS Standard signals
367 Linux supports the standard signals listed below.
368 The second column of the table indicates which standard (if any)
369 specified the signal: "P1990" indicates that the signal is described
370 in the original POSIX.1-1990 standard;
371 "P2001" indicates that the signal was added in SUSv2 and POSIX.1-2001.
372 .TS
373 l c c l
374 ____
375 lB c c l.
376 Signal Standard Action Comment
377 SIGABRT P1990 Core Abort signal from \fBabort\fP(3)
378 SIGALRM P1990 Term Timer signal from \fBalarm\fP(2)
379 SIGBUS P2001 Core Bus error (bad memory access)
380 SIGCHLD P1990 Ign Child stopped or terminated
381 SIGCLD \- Ign A synonym for \fBSIGCHLD\fP
382 SIGCONT P1990 Cont Continue if stopped
383 SIGEMT \- Term Emulator trap
384 SIGFPE P1990 Core Floating-point exception
385 SIGHUP P1990 Term Hangup detected on controlling terminal
386 or death of controlling process
387 SIGILL P1990 Core Illegal Instruction
388 SIGINFO \- A synonym for \fBSIGPWR\fP
389 SIGINT P1990 Term Interrupt from keyboard
390 SIGIO \- Term I/O now possible (4.2BSD)
391 SIGIOT \- Core IOT trap. A synonym for \fBSIGABRT\fP
392 SIGKILL P1990 Term Kill signal
393 SIGLOST \- Term File lock lost (unused)
394 SIGPIPE P1990 Term Broken pipe: write to pipe with no
395 readers; see \fBpipe\fP(7)
396 SIGPOLL P2001 Term Pollable event (Sys V);
397 synonym for \fBSIGIO\fP
398 SIGPROF P2001 Term Profiling timer expired
399 SIGPWR \- Term Power failure (System V)
400 SIGQUIT P1990 Core Quit from keyboard
401 SIGSEGV P1990 Core Invalid memory reference
402 SIGSTKFLT \- Term Stack fault on coprocessor (unused)
403 SIGSTOP P1990 Stop Stop process
404 SIGTSTP P1990 Stop Stop typed at terminal
405 SIGSYS P2001 Core Bad system call (SVr4);
406 see also \fBseccomp\fP(2)
407 SIGTERM P1990 Term Termination signal
408 SIGTRAP P2001 Core Trace/breakpoint trap
409 SIGTTIN P1990 Stop Terminal input for background process
410 SIGTTOU P1990 Stop Terminal output for background process
411 SIGUNUSED \- Core Synonymous with \fBSIGSYS\fP
412 SIGURG P2001 Ign Urgent condition on socket (4.2BSD)
413 SIGUSR1 P1990 Term User-defined signal 1
414 SIGUSR2 P1990 Term User-defined signal 2
415 SIGVTALRM P2001 Term Virtual alarm clock (4.2BSD)
416 SIGXCPU P2001 Core CPU time limit exceeded (4.2BSD);
417 see \fBsetrlimit\fP(2)
418 SIGXFSZ P2001 Core File size limit exceeded (4.2BSD);
419 see \fBsetrlimit\fP(2)
420 SIGWINCH \- Ign Window resize signal (4.3BSD, Sun)
421 .TE
422 .PP
423 The signals
424 .B SIGKILL
425 and
426 .B SIGSTOP
427 cannot be caught, blocked, or ignored.
428 .PP
429 Up to and including Linux 2.2, the default behavior for
430 .BR SIGSYS ", " SIGXCPU ", " SIGXFSZ ,
431 and (on architectures other than SPARC and MIPS)
432 .B SIGBUS
433 was to terminate the process (without a core dump).
434 (On some other UNIX systems the default action for
435 .BR SIGXCPU " and " SIGXFSZ
436 is to terminate the process without a core dump.)
437 Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals,
438 terminating the process with a core dump.
439 .PP
440 .B SIGEMT
441 is not specified in POSIX.1-2001, but nevertheless appears
442 on most other UNIX systems,
443 where its default action is typically to terminate
444 the process with a core dump.
445 .PP
446 .B SIGPWR
447 (which is not specified in POSIX.1-2001) is typically ignored
448 by default on those other UNIX systems where it appears.
449 .PP
450 .B SIGIO
451 (which is not specified in POSIX.1-2001) is ignored by default
452 on several other UNIX systems.
453 .\"
454 .SS Queueing and delivery semantics for standard signals
455 If multiple standard signals are pending for a process,
456 the order in which the signals are delivered is unspecified.
457 .PP
458 Standard signals do not queue.
459 If multiple instances of a standard signal are generated while
460 that signal is blocked,
461 then only one instance of the signal is marked as pending
462 (and the signal will be delivered just once when it is unblocked).
463 In the case where a standard signal is already pending, the
464 .I siginfo_t
465 structure (see
466 .BR sigaction (2))
467 associated with that signal is not overwritten
468 on arrival of subsequent instances of the same signal.
469 Thus, the process will receive the information
470 associated with the first instance of the signal.
471 .\"
472 .SS Signal numbering for standard signals
473 The numeric value for each signal is given in the table below.
474 As shown in the table, many signals have different numeric values
475 on different architectures.
476 The first numeric value in each table row shows the signal number
477 on x86, ARM, and most other architectures;
478 the second value is for Alpha and SPARC; the third is for MIPS;
479 and the last is for PARISC.
480 A dash (\-) denotes that a signal is absent on the corresponding architecture.
481 .TS
482 l c c c c l
483 l c c c c l
484 ______
485 lB c c c c l.
486 Signal x86/ARM Alpha/ MIPS PARISC Notes
487 most others SPARC
488 SIGHUP \01 \01 \01 \01
489 SIGINT \02 \02 \02 \02
490 SIGQUIT \03 \03 \03 \03
491 SIGILL \04 \04 \04 \04
492 SIGTRAP \05 \05 \05 \05
493 SIGABRT \06 \06 \06 \06
494 SIGIOT \06 \06 \06 \06
495 SIGBUS \07 10 10 10
496 SIGEMT \- \07 \07 -
497 SIGFPE \08 \08 \08 \08
498 SIGKILL \09 \09 \09 \09
499 SIGUSR1 10 30 16 16
500 SIGSEGV 11 11 11 11
501 SIGUSR2 12 31 17 17
502 SIGPIPE 13 13 13 13
503 SIGALRM 14 14 14 14
504 SIGTERM 15 15 15 15
505 SIGSTKFLT 16 \- \- \07
506 SIGCHLD 17 20 18 18
507 SIGCLD \- \- 18 \-
508 SIGCONT 18 19 25 26
509 SIGSTOP 19 17 23 24
510 SIGTSTP 20 18 24 25
511 SIGTTIN 21 21 26 27
512 SIGTTOU 22 22 27 28
513 SIGURG 23 16 21 29
514 SIGXCPU 24 24 30 12
515 SIGXFSZ 25 25 31 30
516 SIGVTALRM 26 26 28 20
517 SIGPROF 27 27 29 21
518 SIGWINCH 28 28 20 23
519 SIGIO 29 23 22 22
520 SIGPOLL Same as SIGIO
521 SIGPWR 30 29/\- 19 19
522 SIGINFO \- 29/\- \- \-
523 SIGLOST \- \-/29 \- \-
524 SIGSYS 31 12 12 31
525 SIGUNUSED 31 \- \- 31
526 .TE
527 .PP
528 Note the following:
529 .IP * 3
530 Where defined,
531 .B SIGUNUSED
532 is synonymous with
533 .BR SIGSYS .
534 Since glibc 2.26,
535 .B SIGUNUSED
536 is no longer defined on any architecture.
537 .IP *
538 Signal 29 is
539 .BR SIGINFO / SIGPWR
540 (synonyms for the same value) on Alpha but
541 .B SIGLOST
542 on SPARC.
543 .\"
544 .SS Real-time signals
545 Starting with version 2.2,
546 Linux supports real-time signals as originally defined in the POSIX.1b
547 real-time extensions (and now included in POSIX.1-2001).
548 The range of supported real-time signals is defined by the macros
549 .B SIGRTMIN
550 and
551 .BR SIGRTMAX .
552 POSIX.1-2001 requires that an implementation support at least
553 .B _POSIX_RTSIG_MAX
554 (8) real-time signals.
555 .PP
556 The Linux kernel supports a range of 33 different real-time
557 signals, numbered 32 to 64.
558 However, the glibc POSIX threads implementation internally uses
559 two (for NPTL) or three (for LinuxThreads) real-time signals
560 (see
561 .BR pthreads (7)),
562 and adjusts the value of
563 .B SIGRTMIN
564 suitably (to 34 or 35).
565 Because the range of available real-time signals varies according
566 to the glibc threading implementation (and this variation can occur
567 at run time according to the available kernel and glibc),
568 and indeed the range of real-time signals varies across UNIX systems,
569 programs should
570 .IR "never refer to real-time signals using hard-coded numbers" ,
571 but instead should always refer to real-time signals using the notation
572 .BR SIGRTMIN +n,
573 and include suitable (run-time) checks that
574 .BR SIGRTMIN +n
575 does not exceed
576 .BR SIGRTMAX .
577 .PP
578 Unlike standard signals, real-time signals have no predefined meanings:
579 the entire set of real-time signals can be used for application-defined
580 purposes.
581 .PP
582 The default action for an unhandled real-time signal is to terminate the
583 receiving process.
584 .PP
585 Real-time signals are distinguished by the following:
586 .IP 1. 4
587 Multiple instances of real-time signals can be queued.
588 By contrast, if multiple instances of a standard signal are delivered
589 while that signal is currently blocked, then only one instance is queued.
590 .IP 2. 4
591 If the signal is sent using
592 .BR sigqueue (3),
593 an accompanying value (either an integer or a pointer) can be sent
594 with the signal.
595 If the receiving process establishes a handler for this signal using the
596 .B SA_SIGINFO
597 flag to
598 .BR sigaction (2),
599 then it can obtain this data via the
600 .I si_value
601 field of the
602 .I siginfo_t
603 structure passed as the second argument to the handler.
604 Furthermore, the
605 .I si_pid
606 and
607 .I si_uid
608 fields of this structure can be used to obtain the PID
609 and real user ID of the process sending the signal.
610 .IP 3. 4
611 Real-time signals are delivered in a guaranteed order.
612 Multiple real-time signals of the same type are delivered in the order
613 they were sent.
614 If different real-time signals are sent to a process, they are delivered
615 starting with the lowest-numbered signal.
616 (I.e., low-numbered signals have highest priority.)
617 By contrast, if multiple standard signals are pending for a process,
618 the order in which they are delivered is unspecified.
619 .PP
620 If both standard and real-time signals are pending for a process,
621 POSIX leaves it unspecified which is delivered first.
622 Linux, like many other implementations, gives priority
623 to standard signals in this case.
624 .PP
625 According to POSIX, an implementation should permit at least
626 .B _POSIX_SIGQUEUE_MAX
627 (32) real-time signals to be queued to
628 a process.
629 However, Linux does things differently.
630 In kernels up to and including 2.6.7, Linux imposes
631 a system-wide limit on the number of queued real-time signals
632 for all processes.
633 This limit can be viewed and (with privilege) changed via the
634 .I /proc/sys/kernel/rtsig\-max
635 file.
636 A related file,
637 .IR /proc/sys/kernel/rtsig\-nr ,
638 can be used to find out how many real-time signals are currently queued.
639 In Linux 2.6.8, these
640 .I /proc
641 interfaces were replaced by the
642 .B RLIMIT_SIGPENDING
643 resource limit, which specifies a per-user limit for queued
644 signals; see
645 .BR setrlimit (2)
646 for further details.
647 .PP
648 The addition of real-time signals required the widening
649 of the signal set structure
650 .RI ( sigset_t )
651 from 32 to 64 bits.
652 Consequently, various system calls were superseded by new system calls
653 that supported the larger signal sets.
654 The old and new system calls are as follows:
655 .TS
656 lb lb
657 l l.
658 Linux 2.0 and earlier Linux 2.2 and later
659 \fBsigaction\fP(2) \fBrt_sigaction\fP(2)
660 \fBsigpending\fP(2) \fBrt_sigpending\fP(2)
661 \fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2)
662 \fBsigreturn\fP(2) \fBrt_sigreturn\fP(2)
663 \fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2)
664 \fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2)
665 .TE
666 .\"
667 .SS Interruption of system calls and library functions by signal handlers
668 If a signal handler is invoked while a system call or library
669 function call is blocked, then either:
670 .IP * 2
671 the call is automatically restarted after the signal handler returns; or
672 .IP *
673 the call fails with the error
674 .BR EINTR .
675 .PP
676 Which of these two behaviors occurs depends on the interface and
677 whether or not the signal handler was established using the
678 .BR SA_RESTART
679 flag (see
680 .BR sigaction (2)).
681 The details vary across UNIX systems;
682 below, the details for Linux.
683 .PP
684 If a blocked call to one of the following interfaces is interrupted
685 by a signal handler, then the call is automatically restarted
686 after the signal handler returns if the
687 .BR SA_RESTART
688 flag was used; otherwise the call fails with the error
689 .BR EINTR :
690 .\" The following system calls use ERESTARTSYS,
691 .\" so that they are restartable
692 .IP * 2
693 .BR read (2),
694 .BR readv (2),
695 .BR write (2),
696 .BR writev (2),
697 and
698 .BR ioctl (2)
699 calls on "slow" devices.
700 A "slow" device is one where the I/O call may block for an
701 indefinite time, for example, a terminal, pipe, or socket.
702 If an I/O call on a slow device has already transferred some
703 data by the time it is interrupted by a signal handler,
704 then the call will return a success status
705 (normally, the number of bytes transferred).
706 Note that a (local) disk is not a slow device according to this definition;
707 I/O operations on disk devices are not interrupted by signals.
708 .IP *
709 .BR open (2),
710 if it can block (e.g., when opening a FIFO; see
711 .BR fifo (7)).
712 .IP *
713 .BR wait (2),
714 .BR wait3 (2),
715 .BR wait4 (2),
716 .BR waitid (2),
717 and
718 .BR waitpid (2).
719 .IP *
720 Socket interfaces:
721 .\" If a timeout (setsockopt()) is in effect on the socket, then these
722 .\" system calls switch to using EINTR. Consequently, they and are not
723 .\" automatically restarted, and they show the stop/cont behavior
724 .\" described below. (Verified from 2.6.26 source, and by experiment; mtk)
725 .BR accept (2),
726 .BR connect (2),
727 .BR recv (2),
728 .BR recvfrom (2),
729 .BR recvmmsg (2),
730 .BR recvmsg (2),
731 .BR send (2),
732 .BR sendto (2),
733 and
734 .BR sendmsg (2),
735 .\" FIXME What about sendmmsg()?
736 unless a timeout has been set on the socket (see below).
737 .IP *
738 File locking interfaces:
739 .BR flock (2)
740 and
741 the
742 .BR F_SETLKW
743 and
744 .BR F_OFD_SETLKW
745 operations of
746 .BR fcntl (2)
747 .IP *
748 POSIX message queue interfaces:
749 .BR mq_receive (3),
750 .BR mq_timedreceive (3),
751 .BR mq_send (3),
752 and
753 .BR mq_timedsend (3).
754 .IP *
755 .BR futex (2)
756 .B FUTEX_WAIT
757 (since Linux 2.6.22;
758 .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a
759 beforehand, always failed with
760 .BR EINTR ).
761 .IP *
762 .BR getrandom (2).
763 .IP *
764 .BR pthread_mutex_lock (3),
765 .BR pthread_cond_wait (3),
766 and related APIs.
767 .IP *
768 .BR futex (2)
769 .BR FUTEX_WAIT_BITSET .
770 .IP *
771 POSIX semaphore interfaces:
772 .BR sem_wait (3)
773 and
774 .BR sem_timedwait (3)
775 (since Linux 2.6.22;
776 .\" as a consequence of the 2.6.22 changes in the futex() implementation
777 beforehand, always failed with
778 .BR EINTR ).
779 .IP *
780 .BR read (2)
781 from an
782 .BR inotify (7)
783 file descriptor
784 (since Linux 3.8;
785 .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
786 beforehand, always failed with
787 .BR EINTR ).
788 .PP
789 The following interfaces are never restarted after
790 being interrupted by a signal handler,
791 regardless of the use of
792 .BR SA_RESTART ;
793 they always fail with the error
794 .B EINTR
795 when interrupted by a signal handler:
796 .\" These are the system calls that give EINTR or ERESTARTNOHAND
797 .\" on interruption by a signal handler.
798 .IP * 2
799 "Input" socket interfaces, when a timeout
800 .RB ( SO_RCVTIMEO )
801 has been set on the socket using
802 .BR setsockopt (2):
803 .BR accept (2),
804 .BR recv (2),
805 .BR recvfrom (2),
806 .BR recvmmsg (2)
807 (also with a non-NULL
808 .IR timeout
809 argument),
810 and
811 .BR recvmsg (2).
812 .IP *
813 "Output" socket interfaces, when a timeout
814 .RB ( SO_RCVTIMEO )
815 has been set on the socket using
816 .BR setsockopt (2):
817 .BR connect (2),
818 .BR send (2),
819 .BR sendto (2),
820 and
821 .BR sendmsg (2).
822 .\" FIXME What about sendmmsg()?
823 .IP *
824 Interfaces used to wait for signals:
825 .BR pause (2),
826 .BR sigsuspend (2),
827 .BR sigtimedwait (2),
828 and
829 .BR sigwaitinfo (2).
830 .IP *
831 File descriptor multiplexing interfaces:
832 .BR epoll_wait (2),
833 .BR epoll_pwait (2),
834 .BR poll (2),
835 .BR ppoll (2),
836 .BR select (2),
837 and
838 .BR pselect (2).
839 .IP *
840 System V IPC interfaces:
841 .\" On some other systems, SA_RESTART does restart these system calls
842 .BR msgrcv (2),
843 .BR msgsnd (2),
844 .BR semop (2),
845 and
846 .BR semtimedop (2).
847 .IP *
848 Sleep interfaces:
849 .BR clock_nanosleep (2),
850 .BR nanosleep (2),
851 and
852 .BR usleep (3).
853 .IP *
854 .BR io_getevents (2).
855 .PP
856 The
857 .BR sleep (3)
858 function is also never restarted if interrupted by a handler,
859 but gives a success return: the number of seconds remaining to sleep.
860 .PP
861 In certain circumstances, the
862 .BR seccomp (2)
863 user-space notification feature can lead to restarting of system calls
864 that would otherwise never be restarted by
865 .BR SA_RESTART ;
866 for details, see
867 .BR seccomp_unotify (2).
868 .\"
869 .SS Interruption of system calls and library functions by stop signals
870 On Linux, even in the absence of signal handlers,
871 certain blocking interfaces can fail with the error
872 .BR EINTR
873 after the process is stopped by one of the stop signals
874 and then resumed via
875 .BR SIGCONT .
876 This behavior is not sanctioned by POSIX.1, and doesn't occur
877 on other systems.
878 .PP
879 The Linux interfaces that display this behavior are:
880 .IP * 2
881 "Input" socket interfaces, when a timeout
882 .RB ( SO_RCVTIMEO )
883 has been set on the socket using
884 .BR setsockopt (2):
885 .BR accept (2),
886 .BR recv (2),
887 .BR recvfrom (2),
888 .BR recvmmsg (2)
889 (also with a non-NULL
890 .IR timeout
891 argument),
892 and
893 .BR recvmsg (2).
894 .IP *
895 "Output" socket interfaces, when a timeout
896 .RB ( SO_RCVTIMEO )
897 has been set on the socket using
898 .BR setsockopt (2):
899 .BR connect (2),
900 .BR send (2),
901 .BR sendto (2),
902 and
903 .\" FIXME What about sendmmsg()?
904 .BR sendmsg (2),
905 if a send timeout
906 .RB ( SO_SNDTIMEO )
907 has been set.
908 .IP * 2
909 .BR epoll_wait (2),
910 .BR epoll_pwait (2).
911 .IP *
912 .BR semop (2),
913 .BR semtimedop (2).
914 .IP *
915 .BR sigtimedwait (2),
916 .BR sigwaitinfo (2).
917 .IP *
918 Linux 3.7 and earlier:
919 .BR read (2)
920 from an
921 .BR inotify (7)
922 file descriptor
923 .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
924 .IP *
925 Linux 2.6.21 and earlier:
926 .BR futex (2)
927 .BR FUTEX_WAIT ,
928 .BR sem_timedwait (3),
929 .BR sem_wait (3).
930 .IP *
931 Linux 2.6.8 and earlier:
932 .BR msgrcv (2),
933 .BR msgsnd (2).
934 .IP *
935 Linux 2.4 and earlier:
936 .BR nanosleep (2).
937 .SH CONFORMING TO
938 POSIX.1, except as noted.
939 .SH NOTES
940 For a discussion of async-signal-safe functions, see
941 .BR signal\-safety (7).
942 .PP
943 The
944 .I /proc/[pid]/task/[tid]/status
945 file contains various fields that show the signals
946 that a thread is blocking
947 .RI ( SigBlk ),
948 catching
949 .RI ( SigCgt ),
950 or ignoring
951 .RI ( SigIgn ).
952 (The set of signals that are caught or ignored will be the same
953 across all threads in a process.)
954 Other fields show the set of pending signals that are directed to the thread
955 .RI ( SigPnd )
956 as well as the set of pending signals that are directed
957 to the process as a whole
958 .RI ( ShdPnd ).
959 The corresponding fields in
960 .I /proc/[pid]/status
961 show the information for the main thread.
962 See
963 .BR proc (5)
964 for further details.
965 .SH BUGS
966 There are six signals that can be delivered
967 as a consequence of a hardware exception:
968 .BR SIGBUS ,
969 .BR SIGEMT ,
970 .BR SIGFPE ,
971 .BR SIGILL ,
972 .BR SIGSEGV ,
973 and
974 .BR SIGTRAP .
975 Which of these signals is delivered,
976 for any given hardware exception,
977 is not documented and does not always make sense.
978 .PP
979 For example, an invalid memory access that causes delivery of
980 .B SIGSEGV
981 on one CPU architecture may cause delivery of
982 .B SIGBUS
983 on another architecture, or vice versa.
984 .PP
985 For another example, using the x86
986 .I int
987 instruction with a forbidden argument
988 (any number other than 3 or 128)
989 causes delivery of
990 .BR SIGSEGV ,
991 even though
992 .B SIGILL
993 would make more sense,
994 because of how the CPU reports the forbidden operation to the kernel.
995 .SH SEE ALSO
996 .BR kill (1),
997 .BR clone (2),
998 .BR getrlimit (2),
999 .BR kill (2),
1000 .BR pidfd_send_signal (2),
1001 .BR restart_syscall (2),
1002 .BR rt_sigqueueinfo (2),
1003 .BR setitimer (2),
1004 .BR setrlimit (2),
1005 .BR sgetmask (2),
1006 .BR sigaction (2),
1007 .BR sigaltstack (2),
1008 .BR signal (2),
1009 .BR signalfd (2),
1010 .BR sigpending (2),
1011 .BR sigprocmask (2),
1012 .BR sigreturn (2),
1013 .BR sigsuspend (2),
1014 .BR sigwaitinfo (2),
1015 .BR abort (3),
1016 .BR bsd_signal (3),
1017 .BR killpg (3),
1018 .BR longjmp (3),
1019 .BR pthread_sigqueue (3),
1020 .BR raise (3),
1021 .BR sigqueue (3),
1022 .BR sigset (3),
1023 .BR sigsetops (3),
1024 .BR sigvec (3),
1025 .BR sigwait (3),
1026 .BR strsignal (3),
1027 .BR swapcontext (3),
1028 .BR sysv_signal (3),
1029 .BR core (5),
1030 .BR proc (5),
1031 .BR nptl (7),
1032 .BR pthreads (7),
1033 .BR sigevent (7)