1SIGNAL(7)                  Linux Programmer's Manual                 SIGNAL(7)
2
3
4

NAME

6       signal - overview of signals
7

DESCRIPTION

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

CONFORMING TO

557       POSIX.1, except as noted.
558

BUGS

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

SEE ALSO

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

COLOPHON

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)
Impressum