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