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<