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(2) 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 -
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
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 argument to routine (SVr4)
183 SIGTRAP 5 Core Trace/breakpoint trap
184 SIGURG 16,23,21 Ign Urgent condition on socket (4.2BSD)
185 SIGVTALRM 26,26,28 Term Virtual alarm clock (4.2BSD)
186 SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2BSD)
187 SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD)
188 Up to and including Linux 2.2, the default behavior for SIGSYS, SIGX‐
190 CPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS
191 was to terminate the process (without a core dump). (On some other
192 UNIX systems the default action for SIGXCPU and SIGXFSZ is to terminate
193 the process without a core dump.) Linux 2.4 conforms to the
194 POSIX.1-2001 requirements for these signals, terminating the process
195 with a core dump.
196 Next various other signals.
198 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 (unused)
209 SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun)
210 SIGUNUSED -,31,- Core Synonymous with SIGSYS
211 (Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)
213 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 SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by
219 default on those other UNIX systems where it appears.
220 SIGIO (which is not specified in POSIX.1-2001) is ignored by default on
222 several other UNIX systems.
223 Where defined, SIGUNUSED is synonymous with SIGSYS on most architec‐
225 tures.
226 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 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 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.
250 The default action for an unhandled real-time signal is to terminate
252 the receiving process.
253 Real-time signals are distinguished by the following:
255 1. Multiple instances of real-time signals can be queued. By con‐
257 trast, if multiple instances of a standard signal are delivered
258 while that signal is currently blocked, then only one instance is
259 queued.
260 2. If the signal is sent using sigqueue(3), an accompanying value
262 (either an integer or a pointer) can be sent with the signal. If
263 the receiving process establishes a handler for this signal using
264 the SA_SIGINFO flag to sigaction(2) then it can obtain this data
265 via the si_value field of the siginfo_t structure passed as the
266 second argument to the handler. Furthermore, the si_pid and si_uid
267 fields of this structure can be used to obtain the PID and real
268 user ID of the process sending the signal.
269 3. Real-time signals are delivered in a guaranteed order. Multiple
271 real-time signals of the same type are delivered in the order they
272 were sent. If different real-time signals are sent to a process,
273 they are delivered starting with the lowest-numbered signal.
274 (I.e., low-numbered signals have highest priority.) By contrast,
275 if multiple standard signals are pending for a process, the order
276 in which they are delivered is unspecified.
277 If both standard and real-time signals are pending for a process, POSIX
279 leaves it unspecified which is delivered first. Linux, like many other
280 implementations, gives priority to standard signals in this case.
281 According to POSIX, an implementation should permit at least
283 _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process.
284 However, Linux does things differently. In kernels up to and including
285 2.6.7, Linux imposes a system-wide limit on the number of queued real-
286 time signals for all processes. This limit can be viewed and (with
287 privilege) changed via the /proc/sys/kernel/rtsig-max file. A related
288 file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-
289 time signals are currently queued. In Linux 2.6.8, these /proc inter‐
290 faces were replaced by the RLIMIT_SIGPENDING resource limit, which
291 specifies a per-user limit for queued signals; see setrlimit(2) for
292 further details.
293 Async-signal-safe functions
295 A signal handler function must be very careful, since processing else‐
296 where may be interrupted at some arbitrary point in the execution of
297 the program. POSIX has the concept of "safe function". If a signal
298 interrupts the execution of an unsafe function, and handler calls an
299 unsafe function, then the behavior of the program is undefined.
300 POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2)
302 requires an implementation to guarantee that the following functions
303 can be safely called inside a signal handler:
304 _Exit()
306 _exit()
307 abort()
308 accept()
309 access()
310 aio_error()
311 aio_return()
312 aio_suspend()
313 alarm()
314 bind()
315 cfgetispeed()
316 cfgetospeed()
317 cfsetispeed()
318 cfsetospeed()
319 chdir()
320 chmod()
321 chown()
322 clock_gettime()
323 close()
324 connect()
325 creat()
326 dup()
327 dup2()
328 execle()
329 execve()
330 fchmod()
331 fchown()
332 fcntl()
333 fdatasync()
334 fork()
335 fpathconf()
336 fstat()
337 fsync()
338 ftruncate()
339 getegid()
340 geteuid()
341 getgid()
342 getgroups()
343 getpeername()
344 getpgrp()
345 getpid()
346 getppid()
347 getsockname()
348 getsockopt()
349 getuid()
350 kill()
351 link()
352 listen()
353 lseek()
354 lstat()
355 mkdir()
356 mkfifo()
357 open()
358 pathconf()
359 pause()
360 pipe()
361 poll()
362 posix_trace_event()
363 pselect()
364 raise()
365 read()
366 readlink()
367 recv()
368 recvfrom()
369 recvmsg()
370 rename()
371 rmdir()
372 select()
373 sem_post()
374 send()
375 sendmsg()
376 sendto()
377 setgid()
378 setpgid()
379 setsid()
380 setsockopt()
381 setuid()
382 shutdown()
383 sigaction()
384 sigaddset()
385 sigdelset()
386 sigemptyset()
387 sigfillset()
388 sigismember()
389 signal()
390 sigpause()
391 sigpending()
392 sigprocmask()
393 sigqueue()
394 sigset()
395 sigsuspend()
396 sleep()
397 sockatmark()
398 socket()
399 socketpair()
400 stat()
401 symlink()
402 sysconf()
403 tcdrain()
404 tcflow()
405 tcflush()
406 tcgetattr()
407 tcgetpgrp()
408 tcsendbreak()
409 tcsetattr()
410 tcsetpgrp()
411 time()
412 timer_getoverrun()
413 timer_gettime()
414 timer_settime()
415 times()
416 umask()
417 uname()
418 unlink()
419 utime()
420 wait()
421 waitpid()
422 write()
423 POSIX.1-2008 removes fpathconf(), pathconf(), and sysconf() from the
425 above list, and adds the following functions:
426 execl()
428 execv()
429 faccessat()
430 fchmodat()
431 fchownat()
432 fexecve()
433 fstatat()
434 futimens()
435 linkat()
436 mkdirat()
437 mkfifoat()
438 mknod()
439 mknodat()
440 openat()
441 readlinkat()
442 renameat()
443 symlinkat()
444 unlinkat()
445 utimensat()
446 utimes()
447 Interruption of system calls and library functions by signal handlers
449 If a signal handler is invoked while a system call or library function
450 call is blocked, then either:
451 * the call is automatically restarted after the signal handler returns;
453 or
454 * the call fails with the error EINTR.
456 Which of these two behaviors occurs depends on the interface and
458 whether or not the signal handler was established using the SA_RESTART
459 flag (see sigaction(2)). The details vary across UNIX systems; below,
460 the details for Linux.
461 If a blocked call to one of the following interfaces is interrupted by
463 a signal handler, then the call will be automatically restarted after
464 the signal handler returns if the SA_RESTART flag was used; otherwise
465 the call will fail with the error EINTR:
466 * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
468 "slow" devices. A "slow" device is one where the I/O call may
469 block for an indefinite time, for example, a terminal, pipe, or
470 socket. (A disk is not a slow device according to this defini‐
471 tion.) If an I/O call on a slow device has already transferred
472 some data by the time it is interrupted by a signal handler, then
473 the call will return a success status (normally, the number of
474 bytes transferred).
475 * open(2), if it can block (e.g., when opening a FIFO; see
477 fifo(7)).
478 * wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
480 * Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2),
482 recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout
483 has been set on the socket (see below).
484 * File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
486 * POSIX message queue interfaces: mq_receive(3), mq_time‐
488 dreceive(3), mq_send(3), and mq_timedsend(3).
489 * futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always
491 failed with EINTR).
492 * POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3)
494 (since Linux 2.6.22; beforehand, always failed with EINTR).
495 The following interfaces are never restarted after being interrupted by
497 a signal handler, regardless of the use of SA_RESTART; they always fail
498 with the error EINTR when interrupted by a signal handler:
499 * Socket interfaces, when a timeout has been set on the socket
501 using setsockopt(2): accept(2), recv(2), recvfrom(2), and
502 recvmsg(2), if a receive timeout (SO_RCVTIMEO) has been set; con‐
503 nect(2), send(2), sendto(2), and sendmsg(2), if a send timeout
504 (SO_SNDTIMEO) has been set.
505 * Interfaces used to wait for signals: pause(2), sigsuspend(2),
507 sigtimedwait(2), and sigwaitinfo(2).
508 * File descriptor multiplexing interfaces: epoll_wait(2),
510 epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).
511 * System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and sem‐
513 timedop(2).
514 * Sleep interfaces: clock_nanosleep(2), nanosleep(2), and
516 usleep(3).
517 * read(2) from an inotify(7) file descriptor.
519 * io_getevents(2).
521 The sleep(3) function is also never restarted if interrupted by a han‐
523 dler, but gives a success return: the number of seconds remaining to
524 sleep.
525 Interruption of system calls and library functions by stop signals
527 On Linux, even in the absence of signal handlers, certain blocking
528 interfaces can fail with the error EINTR after the process is stopped
529 by one of the stop signals and then resumed via SIGCONT. This behavior
530 is not sanctioned by POSIX.1, and doesn't occur on other systems.
531 The Linux interfaces that display this behavior are:
533 * Socket interfaces, when a timeout has been set on the socket
535 using setsockopt(2): accept(2), recv(2), recvfrom(2), and
536 recvmsg(2), if a receive timeout (SO_RCVTIMEO) has been set; con‐
537 nect(2), send(2), sendto(2), and sendmsg(2), if a send timeout
538 (SO_SNDTIMEO) has been set.
539 * epoll_wait(2), epoll_pwait(2).
541 * semop(2), semtimedop(2).
543 * sigtimedwait(2), sigwaitinfo(2).
545 * read(2) from an inotify(7) file descriptor.
547 * Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, sem_timedwait(3),
549 sem_wait(3).
550 * Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2).
552 * Linux 2.4 and earlier: nanosleep(2).
554
556 POSIX.1, except as noted.
557
559 kill(1), getrlimit(2), kill(2), killpg(2), restart_syscall(2),
560 rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigac‐
561 tion(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sig‐
562 procmask(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3),
563 longjmp(3), raise(3), pthread_sigqueue(3), sigqueue(3), sigset(3),
564 sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3),
565 core(5), proc(5), pthreads(7), sigevent(7)
566
568 This page is part of release 3.53 of the Linux man-pages project. A
569 description of the project, and information about reporting bugs, can
570 be found at http://www.kernel.org/doc/man-pages/.
571Linux 2013-07-30 SIGNAL(7)