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