1SIGNAL(7) Linux Programmer's Manual SIGNAL(7)
2
3
4
6 signal - overview of signals
7
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 tables below specify the
17 default disposition for each signal, as follows:
18
19 Term Default action is to terminate the process.
20
21 Ign Default action is to ignore the signal.
22
23 Core Default action is to terminate the process and dump core (see
24 core(5)).
25
26 Stop Default action is to stop the process.
27
28 Cont Default action is to continue the process if it is currently
29 stopped.
30
31 A process can change the disposition of a signal using sigaction(2) or
32 signal(2). (The latter is less portable when establishing a signal
33 handler; see signal(2) for details.) Using these system calls, a
34 process can elect one of the following behaviors to occur on delivery
35 of the signal: perform the default action; ignore the signal; or catch
36 the signal with a signal handler, a programmer-defined function that is
37 automatically invoked when the signal is delivered. (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
43 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
47 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
52 Sending a Signal
53 The following system calls and library functions allow the caller to
54 send a signal:
55
56 raise(3) Sends a signal to the calling thread.
57
58 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
62 killpg(2) Sends a signal to all of the members of a specified
63 process group.
64
65 pthread_kill(3) Sends a signal to a specified POSIX thread in the same
66 process as the caller.
67
68 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
72 sigqueue(2) Sends a real-time signal with accompanying data to a
73 specified process.
74
75 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
80 pause(2) Suspends execution until any signal is caught.
81
82 sigsuspend(2) Temporarily changes the signal mask (see below) and
83 suspends execution until one of the unmasked signals is
84 caught.
85
86 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
93 * 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
97 * 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
104 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
109 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
115 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
118 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
128 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
133 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
136 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 ix86, ia64, ppc, s390, arm and sh, and
141 the last one for mips. A - denotes that a signal is absent on the cor‐
142 responding architecture.)
143
144 First the signals described in the original POSIX.1-1990 standard.
145
146 Signal Value Action Comment
147 ──────────────────────────────────────────────────────────────────────
148 SIGHUP 1 Term Hangup detected on controlling terminal
149 or death of controlling process
150 SIGINT 2 Term Interrupt from keyboard
151 SIGQUIT 3 Core Quit from keyboard
152 SIGILL 4 Core Illegal Instruction
153 SIGABRT 6 Core Abort signal from abort(3)
154 SIGFPE 8 Core Floating point exception
155 SIGKILL 9 Term Kill signal
156 SIGSEGV 11 Core Invalid memory reference
157 SIGPIPE 13 Term Broken pipe: write to pipe with no
158 readers
159 SIGALRM 14 Term Timer signal from alarm(2)
160 SIGTERM 15 Term Termination signal
161 SIGUSR1 30,10,16 Term User-defined signal 1
162 SIGUSR2 31,12,17 Term User-defined signal 2
163 SIGCHLD 20,17,18 Ign Child stopped or terminated
164 SIGCONT 19,18,25 Cont Continue if stopped
165 SIGSTOP 17,19,23 Stop Stop process
166 SIGTSTP 18,20,24 Stop Stop typed at tty
167 SIGTTIN 21,21,26 Stop tty input for background process
168 SIGTTOU 22,22,27 Stop tty output for background process
169
170 The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
171
172 Next the signals not in the POSIX.1-1990 standard but described in
173 SUSv2 and POSIX.1-2001.
174
175 Signal Value Action Comment
176 ────────────────────────────────────────────────────────────────────
177 SIGBUS 10,7,10 Core Bus error (bad memory access)
178 SIGPOLL Term Pollable event (Sys V).
179 Synonym for SIGIO
180 SIGPROF 27,27,29 Term Profiling timer expired
181 SIGSYS 12,31,12 Core Bad argument to routine (SVr4)
182 SIGTRAP 5 Core Trace/breakpoint trap
183 SIGURG 16,23,21 Ign Urgent condition on socket (4.2BSD)
184 SIGVTALRM 26,26,28 Term Virtual alarm clock (4.2BSD)
185 SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2BSD)
186 SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD)
187
188 Up to and including Linux 2.2, the default behavior for SIGSYS, SIGX‐
189 CPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS
190 was to terminate the process (without a core dump). (On some other
191 Unix systems the default action for SIGXCPU and SIGXFSZ is to terminate
192 the process without a core dump.) Linux 2.4 conforms to the
193 POSIX.1-2001 requirements for these signals, terminating the process
194 with a core dump.
195
196 Next various other signals.
197
198
199 Signal Value Action Comment
200 ────────────────────────────────────────────────────────────────────
201 SIGIOT 6 Core IOT trap. A synonym for SIGABRT
202 SIGEMT 7,-,7 Term
203 SIGSTKFLT -,16,- Term Stack fault on coprocessor (unused)
204 SIGIO 23,29,22 Term I/O now possible (4.2BSD)
205 SIGCLD -,-,18 Ign A synonym for SIGCHLD
206 SIGPWR 29,30,19 Term Power failure (System V)
207 SIGINFO 29,-,- A synonym for SIGPWR
208 SIGLOST -,-,- Term File lock lost
209 SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun)
210 SIGUNUSED -,31,- Core Synonymous with SIGSYS
211
212 (Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)
213
214 SIGEMT is not specified in POSIX.1-2001, but nevertheless appears on
215 most other Unix systems, where its default action is typically to ter‐
216 minate the process with a core dump.
217
218 SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by
219 default on those other Unix systems where it appears.
220
221 SIGIO (which is not specified in POSIX.1-2001) is ignored by default on
222 several other Unix systems.
223
224 Where defined, SIGUNUSED is synonymous with SIGSYS on most architec‐
225 tures.
226
227 Real-time Signals
228 Linux supports real-time signals as originally defined in the POSIX.1b
229 real-time extensions (and now included in POSIX.1-2001). The range of
230 supported real-time signals is defined by the macros SIGRTMIN and
231 SIGRTMAX. POSIX.1-2001 requires that an implementation support at
232 least _POSIX_RTSIG_MAX (8) real-time signals.
233
234 The Linux kernel supports a range of 32 different real-time signals,
235 numbered 33 to 64. However, the glibc POSIX threads implementation
236 internally uses two (for NPTL) or three (for LinuxThreads) real-time
237 signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably
238 (to 34 or 35). Because the range of available real-time signals varies
239 according to the glibc threading implementation (and this variation can
240 occur at run time according to the available kernel and glibc), and
241 indeed the range of real-time signals varies across Unix systems, pro‐
242 grams should never refer to real-time signals using hard-coded numbers,
243 but instead should always refer to real-time signals using the notation
244 SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does
245 not exceed SIGRTMAX.
246
247 Unlike standard signals, real-time signals have no predefined meanings:
248 the entire set of real-time signals can be used for application-defined
249 purposes. (Note, however, that the LinuxThreads implementation uses
250 the first three real-time signals.)
251
252 The default action for an unhandled real-time signal is to terminate
253 the receiving process.
254
255 Real-time signals are distinguished by the following:
256
257 1. Multiple instances of real-time signals can be queued. By con‐
258 trast, if multiple instances of a standard signal are delivered
259 while that signal is currently blocked, then only one instance is
260 queued.
261
262 2. If the signal is sent using sigqueue(2), an accompanying value
263 (either an integer or a pointer) can be sent with the signal. If
264 the receiving process establishes a handler for this signal using
265 the SA_SIGINFO flag to sigaction(2) then it can obtain this data
266 via the si_value field of the siginfo_t structure passed as the
267 second argument to the handler. Furthermore, the si_pid and si_uid
268 fields of this structure can be used to obtain the PID and real
269 user ID of the process sending the signal.
270
271 3. Real-time signals are delivered in a guaranteed order. Multiple
272 real-time signals of the same type are delivered in the order they
273 were sent. If different real-time signals are sent to a process,
274 they are delivered starting with the lowest-numbered signal.
275 (I.e., low-numbered signals have highest priority.) By contrast,
276 if multiple standard signals are pending for a process, the order
277 in which they are delivered is unspecified.
278
279 If both standard and real-time signals are pending for a process, POSIX
280 leaves it unspecified which is delivered first. Linux, like many other
281 implementations, gives priority to standard signals in this case.
282
283 According to POSIX, an implementation should permit at least
284 _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process.
285 However, Linux does things differently. In kernels up to and including
286 2.6.7, Linux imposes a system-wide limit on the number of queued real-
287 time signals for all processes. This limit can be viewed and (with
288 privilege) changed via the /proc/sys/kernel/rtsig-max file. A related
289 file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-
290 time signals are currently queued. In Linux 2.6.8, these /proc inter‐
291 faces were replaced by the RLIMIT_SIGPENDING resource limit, which
292 specifies a per-user limit for queued signals; see setrlimit(2) for
293 further details.
294
295 Async-signal-safe functions
296 A signal handler function must be very careful, since processing else‐
297 where may be interrupted at some arbitrary point in the execution of
298 the program. POSIX has the concept of "safe function". If a signal
299 interrupts the execution of an unsafe function, and handler calls an
300 unsafe function, then the behavior of the program is undefined.
301
302 POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2)
303 requires an implementation to guarantee that the following functions
304 can be safely called inside a signal handler:
305
306 _Exit()
307 _exit()
308 abort()
309 accept()
310 access()
311 aio_error()
312 aio_return()
313 aio_suspend()
314 alarm()
315 bind()
316 cfgetispeed()
317 cfgetospeed()
318 cfsetispeed()
319 cfsetospeed()
320 chdir()
321 chmod()
322 chown()
323 clock_gettime()
324 close()
325 connect()
326 creat()
327 dup()
328 dup2()
329 execle()
330 execve()
331 fchmod()
332 fchown()
333 fcntl()
334 fdatasync()
335 fork()
336 fpathconf()
337 fstat()
338 fsync()
339 ftruncate()
340 getegid()
341 geteuid()
342 getgid()
343 getgroups()
344 getpeername()
345 getpgrp()
346 getpid()
347 getppid()
348 getsockname()
349 getsockopt()
350 getuid()
351 kill()
352 link()
353 listen()
354 lseek()
355 lstat()
356 mkdir()
357 mkfifo()
358 open()
359 pathconf()
360 pause()
361 pipe()
362 poll()
363 posix_trace_event()
364 pselect()
365 raise()
366 read()
367 readlink()
368 recv()
369 recvfrom()
370 recvmsg()
371 rename()
372 rmdir()
373 select()
374 sem_post()
375 send()
376 sendmsg()
377 sendto()
378 setgid()
379 setpgid()
380 setsid()
381 setsockopt()
382 setuid()
383 shutdown()
384 sigaction()
385 sigaddset()
386 sigdelset()
387 sigemptyset()
388 sigfillset()
389 sigismember()
390 signal()
391 sigpause()
392 sigpending()
393 sigprocmask()
394 sigqueue()
395 sigset()
396 sigsuspend()
397 sleep()
398 sockatmark()
399 socket()
400 socketpair()
401 stat()
402 symlink()
403 sysconf()
404 tcdrain()
405 tcflow()
406 tcflush()
407 tcgetattr()
408 tcgetpgrp()
409 tcsendbreak()
410 tcsetattr()
411 tcsetpgrp()
412 time()
413 timer_getoverrun()
414 timer_gettime()
415 timer_settime()
416 times()
417 umask()
418 uname()
419 unlink()
420 utime()
421 wait()
422 waitpid()
423 write()
424
425 POSIX.1-2008 removes fpathconf(), pathconf(), and sysconf() from the
426 above list, and adds the following functions:
427
428 execl()
429 execv()
430 faccessat()
431 fchmodat()
432 fchownat()
433 fexecve()
434 fstatat()
435 futimens()
436 linkat()
437 mkdirat()
438 mkfifoat()
439 mknod()
440 mknodat()
441 openat()
442 readlinkat()
443 renameat()
444 symlinkat()
445 unlinkat()
446 utimensat()
447 utimes()
448
449 Interruption of System Calls and Library Functions by Signal Handlers
450 If a signal handler is invoked while a system call or library function
451 call is blocked, then either:
452
453 * the call is automatically restarted after the signal handler returns;
454 or
455
456 * the call fails with the error EINTR.
457
458 Which of these two behaviors occurs depends on the interface and
459 whether or not the signal handler was established using the SA_RESTART
460 flag (see sigaction(2)). The details vary across Unix systems; below,
461 the details for Linux.
462
463 If a blocked call to one of the following interfaces is interrupted by
464 a signal handler, then the call will be automatically restarted after
465 the signal handler returns if the SA_RESTART flag was used; otherwise
466 the call will fail with the error EINTR:
467
468 * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
469 "slow" devices. A "slow" device is one where the I/O call may
470 block for an indefinite time, for example, a terminal, pipe, or
471 socket. (A disk is not a slow device according to this defini‐
472 tion.) If an I/O call on a slow device has already transferred
473 some data by the time it is interrupted by a signal handler, then
474 the call will return a success status (normally, the number of
475 bytes transferred).
476
477 * open(2), if it can block (e.g., when opening a FIFO; see
478 fifo(7)).
479
480 * wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
481
482 * Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2),
483 recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout
484 has been set on the socket (see below).
485
486 * File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
487
488 * POSIX message queue interfaces: mq_receive(3), mq_time‐
489 dreceive(3), mq_send(3), and mq_timedsend(3).
490
491 * futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always
492 failed with EINTR).
493
494 * POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3)
495 (since Linux 2.6.22; beforehand, always failed with EINTR).
496
497 The following interfaces are never restarted after being interrupted by
498 a signal handler, regardless of the use of SA_RESTART; they always fail
499 with the error EINTR when interrupted by a signal handler:
500
501 * Socket interfaces, when a timeout has been set on the socket
502 using setsockopt(2): accept(2), recv(2), recvfrom(2), and
503 recvmsg(2), if a receive timeout (SO_RCVTIMEO) has been set; con‐
504 nect(2), send(2), sendto(2), and sendmsg(2), if a send timeout
505 (SO_SNDTIMEO) has been set.
506
507 * Interfaces used to wait for signals: pause(2), sigsuspend(2),
508 sigtimedwait(2), and sigwaitinfo(2).
509
510 * File descriptor multiplexing interfaces: epoll_wait(2),
511 epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).
512
513 * System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and sem‐
514 timedop(2).
515
516 * Sleep interfaces: clock_nanosleep(2), nanosleep(2), and
517 usleep(3).
518
519 * read(2) from an inotify(7) file descriptor.
520
521 * io_getevents(2).
522
523 The sleep(3) function is also never restarted if interrupted by a han‐
524 dler, but gives a success return: the number of seconds remaining to
525 sleep.
526
527 Interruption of System Calls and Library Functions by Stop Signals
528 On Linux, even in the absence of signal handlers, certain blocking
529 interfaces can fail with the error EINTR after the process is stopped
530 by one of the stop signals and then resumed via SIGCONT. This behavior
531 is not sanctioned by POSIX.1, and doesn't occur on other systems.
532
533 The Linux interfaces that display this behavior are:
534
535 * Socket interfaces, when a timeout has been set on the socket
536 using setsockopt(2): accept(2), recv(2), recvfrom(2), and
537 recvmsg(2), if a receive timeout (SO_RCVTIMEO) has been set; con‐
538 nect(2), send(2), sendto(2), and sendmsg(2), if a send timeout
539 (SO_SNDTIMEO) has been set.
540
541 * epoll_wait(2), epoll_pwait(2).
542
543 * semop(2), semtimedop(2).
544
545 * sigtimedwait(2), sigwaitinfo(2).
546
547 * read(2) from an inotify(7) file descriptor.
548
549 * Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, sem_timedwait(3),
550 sem_wait(3).
551
552 * Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2).
553
554 * Linux 2.4 and earlier: nanosleep(2).
555
557 POSIX.1, except as noted.
558
560 SIGIO and SIGLOST have the same value. The latter is commented out in
561 the kernel source, but the build process of some software still thinks
562 that signal 29 is SIGLOST.
563
565 kill(1), getrlimit(2), kill(2), killpg(2), setitimer(2), setrlimit(2),
566 sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sig‐
567 pending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), sigwaitinfo(2),
568 abort(3), bsd_signal(3), longjmp(3), raise(3), sigset(3), sigsetops(3),
569 sigvec(3), sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5),
570 pthreads(7)
571
573 This page is part of release 3.25 of the Linux man-pages project. A
574 description of the project, and information about reporting bugs, can
575 be found at http://www.kernel.org/doc/man-pages/.
576
577
578
579Linux 2010-06-12 SIGNAL(7)