diff options
Diffstat (limited to 'man7/signal.7')
| -rw-r--r-- | man7/signal.7 | 1019 |
1 files changed, 0 insertions, 1019 deletions
diff --git a/man7/signal.7 b/man7/signal.7 deleted file mode 100644 index bd2aa8bff..000000000 --- a/man7/signal.7 +++ /dev/null @@ -1,1019 +0,0 @@ -'\" t -.\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) -.\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk <mtk.manpages@gmail.com> -.\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk -.\" <mtk.manpages@gmail.com> -.\" -.\" SPDX-License-Identifier: Linux-man-pages-copyleft -.\" -.\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu) -.\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl) -.\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl) -.\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl) -.\" Modified 10 Apr 2002, by Michael Kerrisk <mtk.manpages@gmail.com> -.\" Modified 7 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com> -.\" Added information on real-time signals -.\" Modified 13 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com> -.\" Noted that SIGSTKFLT is in fact unused -.\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING -.\" 2006-04-24, mtk, Added text on changing signal dispositions, -.\" signal mask, and pending signals. -.\" 2008-07-04, mtk: -.\" Added section on system call restarting (SA_RESTART) -.\" Added section on stop/cont signals interrupting syscalls. -.\" 2008-10-05, mtk: various additions -.\" -.TH signal 7 (date) "Linux man-pages (unreleased)" -.SH NAME -signal \- overview of signals -.SH DESCRIPTION -Linux supports both POSIX reliable signals (hereinafter -"standard signals") and POSIX real-time signals. -.SS Signal dispositions -Each signal has a current -.IR disposition , -which determines how the process behaves when it is delivered -the signal. -.PP -The entries in the "Action" column of the table below specify -the default disposition for each signal, as follows: -.TP -Term -Default action is to terminate the process. -.TP -Ign -Default action is to ignore the signal. -.TP -Core -Default action is to terminate the process and dump core (see -.BR core (5)). -.TP -Stop -Default action is to stop the process. -.TP -Cont -Default action is to continue the process if it is currently stopped. -.PP -A process can change the disposition of a signal using -.BR sigaction (2) -or -.BR signal (2). -(The latter is less portable when establishing a signal handler; -see -.BR signal (2) -for details.) -Using these system calls, a process can elect one of the -following behaviors to occur on delivery of the signal: -perform the default action; ignore the signal; -or catch the signal with a -.IR "signal handler" , -a programmer-defined function that is automatically invoked -when the signal is delivered. -.PP -By default, a signal handler is invoked on the -normal process stack. -It is possible to arrange that the signal handler -uses an alternate stack; see -.BR sigaltstack (2) -for a discussion of how to do this and when it might be useful. -.PP -The signal disposition is a per-process attribute: -in a multithreaded application, the disposition of a -particular signal is the same for all threads. -.PP -A child created via -.BR fork (2) -inherits a copy of its parent's signal dispositions. -During an -.BR execve (2), -the dispositions of handled signals are reset to the default; -the dispositions of ignored signals are left unchanged. -.SS Sending a signal -The following system calls and library functions allow -the caller to send a signal: -.TP -.BR raise (3) -Sends a signal to the calling thread. -.TP -.BR kill (2) -Sends a signal to a specified process, -to all members of a specified process group, -or to all processes on the system. -.TP -.BR pidfd_send_signal (2) -Sends a signal to a process identified by a PID file descriptor. -.TP -.BR killpg (3) -Sends a signal to all of the members of a specified process group. -.TP -.BR pthread_kill (3) -Sends a signal to a specified POSIX thread in the same process as -the caller. -.TP -.BR tgkill (2) -Sends a signal to a specified thread within a specific process. -(This is the system call used to implement -.BR pthread_kill (3).) -.TP -.BR sigqueue (3) -Sends a real-time signal with accompanying data to a specified process. -.SS Waiting for a signal to be caught -The following system calls suspend execution of the calling -thread until a signal is caught -(or an unhandled signal terminates the process): -.TP -.BR pause (2) -Suspends execution until any signal is caught. -.TP -.BR sigsuspend (2) -Temporarily changes the signal mask (see below) and suspends -execution until one of the unmasked signals is caught. -.\" -.SS Synchronously accepting a signal -Rather than asynchronously catching a signal via a signal handler, -it is possible to synchronously accept the signal, that is, -to block execution until the signal is delivered, -at which point the kernel returns information about the -signal to the caller. -There are two general ways to do this: -.IP \[bu] 3 -.BR sigwaitinfo (2), -.BR sigtimedwait (2), -and -.BR sigwait (3) -suspend execution until one of the signals in a specified -set is delivered. -Each of these calls returns information about the delivered signal. -.IP \[bu] -.BR signalfd (2) -returns a file descriptor that can be used to read information -about signals that are delivered to the caller. -Each -.BR read (2) -from this file descriptor blocks until one of the signals -in the set specified in the -.BR signalfd (2) -call is delivered to the caller. -The buffer returned by -.BR read (2) -contains a structure describing the signal. -.SS Signal mask and pending signals -A signal may be -.IR blocked , -which means that it will not be delivered until it is later unblocked. -Between the time when it is generated and when it is delivered -a signal is said to be -.IR pending . -.PP -Each thread in a process has an independent -.IR "signal mask" , -which indicates the set of signals that the thread is currently blocking. -A thread can manipulate its signal mask using -.BR pthread_sigmask (3). -In a traditional single-threaded application, -.BR sigprocmask (2) -can be used to manipulate the signal mask. -.PP -A child created via -.BR fork (2) -inherits a copy of its parent's signal mask; -the signal mask is preserved across -.BR execve (2). -.PP -A signal may be process-directed or thread-directed. -A process-directed signal is one that is targeted at (and thus pending for) -the process as a whole. -A signal may be process-directed -because it was generated by the kernel for reasons -other than a hardware exception, or because it was sent using -.BR kill (2) -or -.BR sigqueue (3). -A thread-directed signal is one that is targeted at a specific thread. -A signal may be thread-directed because it was generated as a consequence -of executing a specific machine-language instruction -that triggered a hardware exception (e.g., -.B SIGSEGV -for an invalid memory access, or -.B SIGFPE -for a math error), or because it was -targeted at a specific thread using -interfaces such as -.BR tgkill (2) -or -.BR pthread_kill (3). -.PP -A process-directed signal may be delivered to any one of the -threads that does not currently have the signal blocked. -.\" Joseph C. Sible notes: -.\" On Linux, if the main thread has the signal unblocked, then the kernel -.\" will always deliver the signal there, citing this kernel code -.\" -.\" Per this comment in kernel/signal.c since time immemorial: -.\" -.\" /* -.\" * Now find a thread we can wake up to take the signal off the queue. -.\" * -.\" * If the main thread wants the signal, it gets first crack. -.\" * Probably the least surprising to the average bear. -.\" */ -.\" -.\" But this does not mean the signal will be delivered only in the -.\" main thread, since if a handler is already executing in the main thread -.\" (and thus the signal is blocked in that thread), then a further -.\" might be delivered in a different thread. -.\" -If more than one of the threads has the signal unblocked, then the -kernel chooses an arbitrary thread to which to deliver the signal. -.PP -A thread can obtain the set of signals that it currently has pending -using -.BR sigpending (2). -This set will consist of the union of the set of pending -process-directed signals and the set of signals pending for -the calling thread. -.PP -A child created via -.BR fork (2) -initially has an empty pending signal set; -the pending signal set is preserved across an -.BR execve (2). -.\" -.SS Execution of signal handlers -Whenever there is a transition from kernel-mode to user-mode execution -(e.g., on return from a system call or scheduling of a thread onto the CPU), -the kernel checks whether there is a pending unblocked signal -for which the process has established a signal handler. -If there is such a pending signal, the following steps occur: -.IP (1) 5 -The kernel performs the necessary preparatory steps for execution of -the signal handler: -.RS -.IP (1.1) 7 -The signal is removed from the set of pending signals. -.IP (1.2) -If the signal handler was installed by a call to -.BR sigaction (2) -that specified the -.B SA_ONSTACK -flag and the thread has defined an alternate signal stack (using -.BR sigaltstack (2)), -then that stack is installed. -.IP (1.3) -Various pieces of signal-related context are saved -into a special frame that is created on the stack. -The saved information includes: -.RS -.IP \[bu] 3 -the program counter register -(i.e., the address of the next instruction in the main program that -should be executed when the signal handler returns); -.IP \[bu] -architecture-specific register state required for resuming the -interrupted program; -.IP \[bu] -the thread's current signal mask; -.IP \[bu] -the thread's alternate signal stack settings. -.RE -.IP -(If the signal handler was installed using the -.BR sigaction (2) -.B SA_SIGINFO -flag, then the above information is accessible via the -.I ucontext_t -object that is pointed to by the third argument of the signal handler.) -.IP (1.4) -Any signals specified in -.I act\->sa_mask -when registering the handler with -.BR sigprocmask (2) -are added to the thread's signal mask. -The signal being delivered is also -added to the signal mask, unless -.B SA_NODEFER -was specified when registering the handler. -These signals are thus blocked while the handler executes. -.RE -.IP (2) -The kernel constructs a frame for the signal handler on the stack. -The kernel sets the program counter for the thread to point to the first -instruction of the signal handler function, -and configures the return address for that function to point to a piece -of user-space code known as the signal trampoline (described in -.BR sigreturn (2)). -.IP (3) -The kernel passes control back to user-space, where execution -commences at the start of the signal handler function. -.IP (4) -When the signal handler returns, control passes to the signal trampoline code. -.IP (5) -The signal trampoline calls -.BR sigreturn (2), -a system call that uses the information in the stack frame created in step 1 -to restore the thread to its state before the signal handler was -called. -The thread's signal mask and alternate signal stack settings -are restored as part of this procedure. -Upon completion of the call to -.BR sigreturn (2), -the kernel transfers control back to user space, -and the thread recommences execution at the point where it was -interrupted by the signal handler. -.PP -Note that if the signal handler does not return -(e.g., control is transferred out of the handler using -.BR siglongjmp (3), -or the handler executes a new program with -.BR execve (2)), -then the final step is not performed. -In particular, in such scenarios it is the programmer's responsibility -to restore the state of the signal mask (using -.BR sigprocmask (2)), -if it is desired to unblock the signals that were blocked on entry -to the signal handler. -(Note that -.BR siglongjmp (3) -may or may not restore the signal mask, depending on the -.I savesigs -value that was specified in the corresponding call to -.BR sigsetjmp (3).) -.PP -From the kernel's point of view, -execution of the signal handler code is exactly the same as the execution -of any other user-space code. -That is to say, the kernel does not record any special state information -indicating that the thread is currently executing inside a signal handler. -All necessary state information is maintained in user-space registers -and the user-space stack. -The depth to which nested signal handlers may be invoked is thus -limited only by the user-space stack (and sensible software design!). -.\" -.SS Standard signals -Linux supports the standard signals listed below. -The second column of the table indicates which standard (if any) -specified the signal: "P1990" indicates that the signal is described -in the original POSIX.1-1990 standard; -"P2001" indicates that the signal was added in SUSv2 and POSIX.1-2001. -.TS -l c c l -____ -lB c c l. -Signal Standard Action Comment -SIGABRT P1990 Core Abort signal from \fBabort\fP(3) -SIGALRM P1990 Term Timer signal from \fBalarm\fP(2) -SIGBUS P2001 Core Bus error (bad memory access) -SIGCHLD P1990 Ign Child stopped or terminated -SIGCLD \- Ign A synonym for \fBSIGCHLD\fP -SIGCONT P1990 Cont Continue if stopped -SIGEMT \- Term Emulator trap -SIGFPE P1990 Core Floating-point exception -SIGHUP P1990 Term Hangup detected on controlling terminal - or death of controlling process -SIGILL P1990 Core Illegal Instruction -SIGINFO \- A synonym for \fBSIGPWR\fP -SIGINT P1990 Term Interrupt from keyboard -SIGIO \- Term I/O now possible (4.2BSD) -SIGIOT \- Core IOT trap. A synonym for \fBSIGABRT\fP -SIGKILL P1990 Term Kill signal -SIGLOST \- Term File lock lost (unused) -SIGPIPE P1990 Term Broken pipe: write to pipe with no - readers; see \fBpipe\fP(7) -SIGPOLL P2001 Term Pollable event (Sys V); - synonym for \fBSIGIO\fP -SIGPROF P2001 Term Profiling timer expired -SIGPWR \- Term Power failure (System V) -SIGQUIT P1990 Core Quit from keyboard -SIGSEGV P1990 Core Invalid memory reference -SIGSTKFLT \- Term Stack fault on coprocessor (unused) -SIGSTOP P1990 Stop Stop process -SIGTSTP P1990 Stop Stop typed at terminal -SIGSYS P2001 Core Bad system call (SVr4); - see also \fBseccomp\fP(2) -SIGTERM P1990 Term Termination signal -SIGTRAP P2001 Core Trace/breakpoint trap -SIGTTIN P1990 Stop Terminal input for background process -SIGTTOU P1990 Stop Terminal output for background process -SIGUNUSED \- Core Synonymous with \fBSIGSYS\fP -SIGURG P2001 Ign Urgent condition on socket (4.2BSD) -SIGUSR1 P1990 Term User-defined signal 1 -SIGUSR2 P1990 Term User-defined signal 2 -SIGVTALRM P2001 Term Virtual alarm clock (4.2BSD) -SIGXCPU P2001 Core CPU time limit exceeded (4.2BSD); - see \fBsetrlimit\fP(2) -SIGXFSZ P2001 Core File size limit exceeded (4.2BSD); - see \fBsetrlimit\fP(2) -SIGWINCH \- Ign Window resize signal (4.3BSD, Sun) -.TE -.PP -The signals -.B SIGKILL -and -.B SIGSTOP -cannot be caught, blocked, or ignored. -.PP -Up to and including Linux 2.2, the default behavior for -.BR SIGSYS ", " SIGXCPU ", " SIGXFSZ , -and (on architectures other than SPARC and MIPS) -.B SIGBUS -was to terminate the process (without a core dump). -(On some other UNIX systems the default action for -.BR SIGXCPU " and " SIGXFSZ -is to terminate the process without a core dump.) -Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, -terminating the process with a core dump. -.PP -.B SIGEMT -is not specified in POSIX.1-2001, but nevertheless appears -on most other UNIX systems, -where its default action is typically to terminate -the process with a core dump. -.PP -.B SIGPWR -(which is not specified in POSIX.1-2001) is typically ignored -by default on those other UNIX systems where it appears. -.PP -.B SIGIO -(which is not specified in POSIX.1-2001) is ignored by default -on several other UNIX systems. -.\" -.SS Queueing and delivery semantics for standard signals -If multiple standard signals are pending for a process, -the order in which the signals are delivered is unspecified. -.PP -Standard signals do not queue. -If multiple instances of a standard signal are generated while -that signal is blocked, -then only one instance of the signal is marked as pending -(and the signal will be delivered just once when it is unblocked). -In the case where a standard signal is already pending, the -.I siginfo_t -structure (see -.BR sigaction (2)) -associated with that signal is not overwritten -on arrival of subsequent instances of the same signal. -Thus, the process will receive the information -associated with the first instance of the signal. -.\" -.SS Signal numbering for standard signals -The numeric value for each signal is given in the table below. -As shown in the table, many signals have different numeric values -on different architectures. -The first numeric value in each table row shows the signal number -on x86, ARM, and most other architectures; -the second value is for Alpha and SPARC; the third is for MIPS; -and the last is for PARISC. -A dash (\-) denotes that a signal is absent on the corresponding architecture. -.TS -l c c c c l -l c c c c l -______ -lB c c c c l. -Signal x86/ARM Alpha/ MIPS PARISC Notes - most others SPARC -SIGHUP \01 \01 \01 \01 -SIGINT \02 \02 \02 \02 -SIGQUIT \03 \03 \03 \03 -SIGILL \04 \04 \04 \04 -SIGTRAP \05 \05 \05 \05 -SIGABRT \06 \06 \06 \06 -SIGIOT \06 \06 \06 \06 -SIGBUS \07 10 10 10 -SIGEMT \- \07 \07 - -SIGFPE \08 \08 \08 \08 -SIGKILL \09 \09 \09 \09 -SIGUSR1 10 30 16 16 -SIGSEGV 11 11 11 11 -SIGUSR2 12 31 17 17 -SIGPIPE 13 13 13 13 -SIGALRM 14 14 14 14 -SIGTERM 15 15 15 15 -SIGSTKFLT 16 \- \- \07 -SIGCHLD 17 20 18 18 -SIGCLD \- \- 18 \- -SIGCONT 18 19 25 26 -SIGSTOP 19 17 23 24 -SIGTSTP 20 18 24 25 -SIGTTIN 21 21 26 27 -SIGTTOU 22 22 27 28 -SIGURG 23 16 21 29 -SIGXCPU 24 24 30 12 -SIGXFSZ 25 25 31 30 -SIGVTALRM 26 26 28 20 -SIGPROF 27 27 29 21 -SIGWINCH 28 28 20 23 -SIGIO 29 23 22 22 -SIGPOLL Same as SIGIO -SIGPWR 30 29/\- 19 19 -SIGINFO \- 29/\- \- \- -SIGLOST \- \-/29 \- \- -SIGSYS 31 12 12 31 -SIGUNUSED 31 \- \- 31 -.TE -.PP -Note the following: -.IP \[bu] 3 -Where defined, -.B SIGUNUSED -is synonymous with -.BR SIGSYS . -Since glibc 2.26, -.B SIGUNUSED -is no longer defined on any architecture. -.IP \[bu] -Signal 29 is -.BR SIGINFO / SIGPWR -(synonyms for the same value) on Alpha but -.B SIGLOST -on SPARC. -.\" -.SS Real-time signals -Starting with Linux 2.2, -Linux supports real-time signals as originally defined in the POSIX.1b -real-time extensions (and now included in POSIX.1-2001). -The range of supported real-time signals is defined by the macros -.B SIGRTMIN -and -.BR SIGRTMAX . -POSIX.1-2001 requires that an implementation support at least -.B _POSIX_RTSIG_MAX -(8) real-time signals. -.PP -The Linux kernel supports a range of 33 different real-time -signals, numbered 32 to 64. -However, the glibc POSIX threads implementation internally uses -two (for NPTL) or three (for LinuxThreads) real-time signals -(see -.BR pthreads (7)), -and adjusts the value of -.B SIGRTMIN -suitably (to 34 or 35). -Because the range of available real-time signals varies according -to the glibc threading implementation (and this variation can occur -at run time according to the available kernel and glibc), -and indeed the range of real-time signals varies across UNIX systems, -programs should -.IR "never refer to real-time signals using hard-coded numbers" , -but instead should always refer to real-time signals using the notation -.BR SIGRTMIN +n, -and include suitable (run-time) checks that -.BR SIGRTMIN +n -does not exceed -.BR SIGRTMAX . -.PP -Unlike standard signals, real-time signals have no predefined meanings: -the entire set of real-time signals can be used for application-defined -purposes. -.PP -The default action for an unhandled real-time signal is to terminate the -receiving process. -.PP -Real-time signals are distinguished by the following: -.IP \[bu] 3 -Multiple instances of real-time signals can be queued. -By contrast, if multiple instances of a standard signal are delivered -while that signal is currently blocked, then only one instance is queued. -.IP \[bu] -If the signal is sent using -.BR sigqueue (3), -an accompanying value (either an integer or a pointer) can be sent -with the signal. -If the receiving process establishes a handler for this signal using the -.B SA_SIGINFO -flag to -.BR sigaction (2), -then it can obtain this data via the -.I si_value -field of the -.I siginfo_t -structure passed as the second argument to the handler. -Furthermore, the -.I si_pid -and -.I si_uid -fields of this structure can be used to obtain the PID -and real user ID of the process sending the signal. -.IP \[bu] -Real-time signals are delivered in a guaranteed order. -Multiple real-time signals of the same type are delivered in the order -they were sent. -If different real-time signals are sent to a process, they are delivered -starting with the lowest-numbered signal. -(I.e., low-numbered signals have highest priority.) -By contrast, if multiple standard signals are pending for a process, -the order in which they are delivered is unspecified. -.PP -If both standard and real-time signals are pending for a process, -POSIX leaves it unspecified which is delivered first. -Linux, like many other implementations, gives priority -to standard signals in this case. -.PP -According to POSIX, an implementation should permit at least -.B _POSIX_SIGQUEUE_MAX -(32) real-time signals to be queued to -a process. -However, Linux does things differently. -Up to and including Linux 2.6.7, Linux imposes -a system-wide limit on the number of queued real-time signals -for all processes. -This limit can be viewed and (with privilege) changed via the -.I /proc/sys/kernel/rtsig\-max -file. -A related file, -.IR /proc/sys/kernel/rtsig\-nr , -can be used to find out how many real-time signals are currently queued. -In Linux 2.6.8, these -.I /proc -interfaces were replaced by the -.B RLIMIT_SIGPENDING -resource limit, which specifies a per-user limit for queued -signals; see -.BR setrlimit (2) -for further details. -.PP -The addition of real-time signals required the widening -of the signal set structure -.RI ( sigset_t ) -from 32 to 64 bits. -Consequently, various system calls were superseded by new system calls -that supported the larger signal sets. -The old and new system calls are as follows: -.TS -lb lb -l l. -Linux 2.0 and earlier Linux 2.2 and later -\fBsigaction\fP(2) \fBrt_sigaction\fP(2) -\fBsigpending\fP(2) \fBrt_sigpending\fP(2) -\fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2) -\fBsigreturn\fP(2) \fBrt_sigreturn\fP(2) -\fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2) -\fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2) -.TE -.\" -.SS Interruption of system calls and library functions by signal handlers -If a signal handler is invoked while a system call or library -function call is blocked, then either: -.IP \[bu] 3 -the call is automatically restarted after the signal handler returns; or -.IP \[bu] -the call fails with the error -.BR EINTR . -.PP -Which of these two behaviors occurs depends on the interface and -whether or not the signal handler was established using the -.B SA_RESTART -flag (see -.BR sigaction (2)). -The details vary across UNIX systems; -below, the details for Linux. -.PP -If a blocked call to one of the following interfaces is interrupted -by a signal handler, then the call is automatically restarted -after the signal handler returns if the -.B SA_RESTART -flag was used; otherwise the call fails with the error -.BR EINTR : -.\" The following system calls use ERESTARTSYS, -.\" so that they are restartable -.IP \[bu] 3 -.BR read (2), -.BR readv (2), -.BR write (2), -.BR writev (2), -and -.BR ioctl (2) -calls on "slow" devices. -A "slow" device is one where the I/O call may block for an -indefinite time, for example, a terminal, pipe, or socket. -If an I/O call on a slow device has already transferred some -data by the time it is interrupted by a signal handler, -then the call will return a success status -(normally, the number of bytes transferred). -Note that a (local) disk is not a slow device according to this definition; -I/O operations on disk devices are not interrupted by signals. -.IP \[bu] -.BR open (2), -if it can block (e.g., when opening a FIFO; see -.BR fifo (7)). -.IP \[bu] -.BR wait (2), -.BR wait3 (2), -.BR wait4 (2), -.BR waitid (2), -and -.BR waitpid (2). -.IP \[bu] -Socket interfaces: -.\" If a timeout (setsockopt()) is in effect on the socket, then these -.\" system calls switch to using EINTR. Consequently, they and are not -.\" automatically restarted, and they show the stop/cont behavior -.\" described below. (Verified from Linux 2.6.26 source, and by experiment; mtk) -.BR accept (2), -.BR connect (2), -.BR recv (2), -.BR recvfrom (2), -.BR recvmmsg (2), -.BR recvmsg (2), -.BR send (2), -.BR sendto (2), -and -.BR sendmsg (2), -.\" FIXME What about sendmmsg()? -unless a timeout has been set on the socket (see below). -.IP \[bu] -File locking interfaces: -.BR flock (2) -and -the -.B F_SETLKW -and -.B F_OFD_SETLKW -operations of -.BR fcntl (2) -.IP \[bu] -POSIX message queue interfaces: -.BR mq_receive (3), -.BR mq_timedreceive (3), -.BR mq_send (3), -and -.BR mq_timedsend (3). -.IP \[bu] -.BR futex (2) -.B FUTEX_WAIT -(since Linux 2.6.22; -.\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a -beforehand, always failed with -.BR EINTR ). -.IP \[bu] -.BR getrandom (2). -.IP \[bu] -.BR pthread_mutex_lock (3), -.BR pthread_cond_wait (3), -and related APIs. -.IP \[bu] -.BR futex (2) -.BR FUTEX_WAIT_BITSET . -.IP \[bu] -POSIX semaphore interfaces: -.BR sem_wait (3) -and -.BR sem_timedwait (3) -(since Linux 2.6.22; -.\" as a consequence of the 2.6.22 changes in the futex() implementation -beforehand, always failed with -.BR EINTR ). -.IP \[bu] -.BR read (2) -from an -.BR inotify (7) -file descriptor -(since Linux 3.8; -.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 -beforehand, always failed with -.BR EINTR ). -.PP -The following interfaces are never restarted after -being interrupted by a signal handler, -regardless of the use of -.BR SA_RESTART ; -they always fail with the error -.B EINTR -when interrupted by a signal handler: -.\" These are the system calls that give EINTR or ERESTARTNOHAND -.\" on interruption by a signal handler. -.IP \[bu] 3 -"Input" socket interfaces, when a timeout -.RB ( SO_RCVTIMEO ) -has been set on the socket using -.BR setsockopt (2): -.BR accept (2), -.BR recv (2), -.BR recvfrom (2), -.BR recvmmsg (2) -(also with a non-NULL -.I timeout -argument), -and -.BR recvmsg (2). -.IP \[bu] -"Output" socket interfaces, when a timeout -.RB ( SO_RCVTIMEO ) -has been set on the socket using -.BR setsockopt (2): -.BR connect (2), -.BR send (2), -.BR sendto (2), -and -.BR sendmsg (2). -.\" FIXME What about sendmmsg()? -.IP \[bu] -Interfaces used to wait for signals: -.BR pause (2), -.BR sigsuspend (2), -.BR sigtimedwait (2), -and -.BR sigwaitinfo (2). -.IP \[bu] -File descriptor multiplexing interfaces: -.BR epoll_wait (2), -.BR epoll_pwait (2), -.BR poll (2), -.BR ppoll (2), -.BR select (2), -and -.BR pselect (2). -.IP \[bu] -System V IPC interfaces: -.\" On some other systems, SA_RESTART does restart these system calls -.BR msgrcv (2), -.BR msgsnd (2), -.BR semop (2), -and -.BR semtimedop (2). -.IP \[bu] -Sleep interfaces: -.BR clock_nanosleep (2), -.BR nanosleep (2), -and -.BR usleep (3). -.IP \[bu] -.BR io_getevents (2). -.PP -The -.BR sleep (3) -function is also never restarted if interrupted by a handler, -but gives a success return: the number of seconds remaining to sleep. -.PP -In certain circumstances, the -.BR seccomp (2) -user-space notification feature can lead to restarting of system calls -that would otherwise never be restarted by -.BR SA_RESTART ; -for details, see -.BR seccomp_unotify (2). -.\" -.SS Interruption of system calls and library functions by stop signals -On Linux, even in the absence of signal handlers, -certain blocking interfaces can fail with the error -.B EINTR -after the process is stopped by one of the stop signals -and then resumed via -.BR SIGCONT . -This behavior is not sanctioned by POSIX.1, and doesn't occur -on other systems. -.PP -The Linux interfaces that display this behavior are: -.IP \[bu] 3 -"Input" socket interfaces, when a timeout -.RB ( SO_RCVTIMEO ) -has been set on the socket using -.BR setsockopt (2): -.BR accept (2), -.BR recv (2), -.BR recvfrom (2), -.BR recvmmsg (2) -(also with a non-NULL -.I timeout -argument), -and -.BR recvmsg (2). -.IP \[bu] -"Output" socket interfaces, when a timeout -.RB ( SO_RCVTIMEO ) -has been set on the socket using -.BR setsockopt (2): -.BR connect (2), -.BR send (2), -.BR sendto (2), -and -.\" FIXME What about sendmmsg()? -.BR sendmsg (2), -if a send timeout -.RB ( SO_SNDTIMEO ) -has been set. -.IP \[bu] -.BR epoll_wait (2), -.BR epoll_pwait (2). -.IP \[bu] -.BR semop (2), -.BR semtimedop (2). -.IP \[bu] -.BR sigtimedwait (2), -.BR sigwaitinfo (2). -.IP \[bu] -Linux 3.7 and earlier: -.BR read (2) -from an -.BR inotify (7) -file descriptor -.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 -.IP \[bu] -Linux 2.6.21 and earlier: -.BR futex (2) -.BR FUTEX_WAIT , -.BR sem_timedwait (3), -.BR sem_wait (3). -.IP \[bu] -Linux 2.6.8 and earlier: -.BR msgrcv (2), -.BR msgsnd (2). -.IP \[bu] -Linux 2.4 and earlier: -.BR nanosleep (2). -.SH STANDARDS -POSIX.1, except as noted. -.SH NOTES -For a discussion of async-signal-safe functions, see -.BR signal\-safety (7). -.PP -The -.IR /proc/ pid /task/ tid /status -file contains various fields that show the signals -that a thread is blocking -.RI ( SigBlk ), -catching -.RI ( SigCgt ), -or ignoring -.RI ( SigIgn ). -(The set of signals that are caught or ignored will be the same -across all threads in a process.) -Other fields show the set of pending signals that are directed to the thread -.RI ( SigPnd ) -as well as the set of pending signals that are directed -to the process as a whole -.RI ( ShdPnd ). -The corresponding fields in -.IR /proc/ pid /status -show the information for the main thread. -See -.BR proc (5) -for further details. -.SH BUGS -There are six signals that can be delivered -as a consequence of a hardware exception: -.BR SIGBUS , -.BR SIGEMT , -.BR SIGFPE , -.BR SIGILL , -.BR SIGSEGV , -and -.BR SIGTRAP . -Which of these signals is delivered, -for any given hardware exception, -is not documented and does not always make sense. -.PP -For example, an invalid memory access that causes delivery of -.B SIGSEGV -on one CPU architecture may cause delivery of -.B SIGBUS -on another architecture, or vice versa. -.PP -For another example, using the x86 -.I int -instruction with a forbidden argument -(any number other than 3 or 128) -causes delivery of -.BR SIGSEGV , -even though -.B SIGILL -would make more sense, -because of how the CPU reports the forbidden operation to the kernel. -.SH SEE ALSO -.BR kill (1), -.BR clone (2), -.BR getrlimit (2), -.BR kill (2), -.BR pidfd_send_signal (2), -.BR restart_syscall (2), -.BR rt_sigqueueinfo (2), -.BR setitimer (2), -.BR setrlimit (2), -.BR sgetmask (2), -.BR sigaction (2), -.BR sigaltstack (2), -.BR signal (2), -.BR signalfd (2), -.BR sigpending (2), -.BR sigprocmask (2), -.BR sigreturn (2), -.BR sigsuspend (2), -.BR sigwaitinfo (2), -.BR abort (3), -.BR bsd_signal (3), -.BR killpg (3), -.BR longjmp (3), -.BR pthread_sigqueue (3), -.BR raise (3), -.BR sigqueue (3), -.BR sigset (3), -.BR sigsetops (3), -.BR sigvec (3), -.BR sigwait (3), -.BR strsignal (3), -.BR swapcontext (3), -.BR sysv_signal (3), -.BR core (5), -.BR proc (5), -.BR nptl (7), -.BR pthreads (7), -.BR sigevent (7) |