1 .\" Copyright (C) 2008 Michael Kerrisk <mtk.manpages@gmail.com>
2 .\" starting from a version by Davide Libenzi <davidel@xmailserver.org>
4 .\" SPDX-License-Identifier: GPL-2.0-or-later
6 .TH SIGNALFD 2 2022-09-17 "Linux man-pages (unreleased)"
8 signalfd \- create a file descriptor for accepting signals
11 .RI ( libc ", " \-lc )
14 .B #include <sys/signalfd.h>
16 .BI "int signalfd(int " fd ", const sigset_t *" mask ", int " flags );
20 creates a file descriptor that can be used to accept signals
21 targeted at the caller.
22 This provides an alternative to the use of a signal handler or
24 and has the advantage that the file descriptor may be monitored by
32 argument specifies the set of signals that the caller
33 wishes to accept via the file descriptor.
34 This argument is a signal set whose contents can be initialized
35 using the macros described in
37 Normally, the set of signals to be received via the
38 file descriptor should be blocked using
40 to prevent the signals being handled according to their default
42 It is not possible to receive
46 signals via a signalfd file descriptor;
47 these signals are silently ignored if specified in
53 then the call creates a new file descriptor and associates the
54 signal set specified in
56 with that file descriptor.
60 then it must specify a valid existing signalfd file descriptor, and
62 is used to replace the signal set associated with that file descriptor.
64 Starting with Linux 2.6.27, the following values may be bitwise ORed in
66 to change the behavior of
72 file status flag on the open file description (see
74 referred to by the new file descriptor.
75 Using this flag saves extra calls to
77 to achieve the same result.
82 flag on the new file descriptor.
83 See the description of the
87 for reasons why this may be useful.
89 In Linux up to version 2.6.26, the
91 argument is unused, and must be specified as zero.
94 returns a file descriptor that supports the following operations:
97 If one or more of the signals specified in
99 is pending for the process, then the buffer supplied to
101 is used to return one or more
103 structures (see below) that describe the signals.
106 returns information for as many signals as are pending and will
107 fit in the supplied buffer.
108 The buffer must be at least
109 .I "sizeof(struct signalfd_siginfo)"
111 The return value of the
113 is the total number of bytes read.
115 As a consequence of the
117 the signals are consumed,
118 so that they are no longer pending for the process
119 (i.e., will not be caught by signal handlers,
120 and cannot be accepted using
121 .BR sigwaitinfo (2)).
123 If none of the signals in
125 is pending for the process, then the
127 either blocks until one of the signals in
129 is generated for the process,
130 or fails with the error
132 if the file descriptor has been made nonblocking.
134 .BR poll "(2), " select "(2) (and similar)"
135 The file descriptor is readable
143 if one or more of the signals in
145 is pending for the process.
147 The signalfd file descriptor also supports the other file-descriptor
155 When the file descriptor is no longer required it should be closed.
156 When all file descriptors associated with the same signalfd object
157 have been closed, the resources for object are freed by the kernel.
158 .SS The signalfd_siginfo structure
161 structure(s) returned by
163 from a signalfd file descriptor is as follows:
167 struct signalfd_siginfo {
168 uint32_t ssi_signo; /* Signal number */
169 int32_t ssi_errno; /* Error number (unused) */
170 int32_t ssi_code; /* Signal code */
171 uint32_t ssi_pid; /* PID of sender */
172 uint32_t ssi_uid; /* Real UID of sender */
173 int32_t ssi_fd; /* File descriptor (SIGIO) */
174 uint32_t ssi_tid; /* Kernel timer ID (POSIX timers)
175 uint32_t ssi_band; /* Band event (SIGIO) */
176 uint32_t ssi_overrun; /* POSIX timer overrun count */
177 uint32_t ssi_trapno; /* Trap number that caused signal */
178 .\" ssi_trapno is unused on most arches
179 int32_t ssi_status; /* Exit status or signal (SIGCHLD) */
180 int32_t ssi_int; /* Integer sent by sigqueue(3) */
181 uint64_t ssi_ptr; /* Pointer sent by sigqueue(3) */
182 uint64_t ssi_utime; /* User CPU time consumed (SIGCHLD) */
183 uint64_t ssi_stime; /* System CPU time consumed
185 uint64_t ssi_addr; /* Address that generated signal
186 (for hardware\-generated signals) */
187 uint16_t ssi_addr_lsb; /* Least significant bit of address
188 (SIGBUS; since Linux 2.6.37) */
189 .\" ssi_addr_lsb: commit b8aeec34175fc8fe8b0d40efea4846dfc1ba663e
190 uint8_t pad[\fIX\fP]; /* Pad size to 128 bytes (allow for
191 additional fields in the future) */
196 Each of the fields in this structure
197 is analogous to the similarly named field in the
202 structure is described in
204 Not all fields in the returned
206 structure will be valid for a specific signal;
207 the set of valid fields can be determined from the value returned in the
210 This field is the analog of the
216 .SS fork(2) semantics
219 the child inherits a copy of the signalfd file descriptor.
222 from the file descriptor in the child will return information
223 about signals queued to the child.
224 .SS Semantics of file descriptor passing
225 As with other file descriptors,
226 signalfd file descriptors can be passed to another process
227 via a UNIX domain socket (see
229 In the receiving process, a
231 from the received file descriptor will return information
232 about signals queued to that process.
233 .SS execve(2) semantics
234 Just like any other file descriptor,
235 a signalfd file descriptor remains open across an
237 unless it has been marked for close-on-exec (see
239 Any signals that were available for reading before the
241 remain available to the newly loaded program.
242 (This is analogous to traditional signal semantics,
243 where a blocked signal that is pending remains pending across an
246 The semantics of signalfd file descriptors in a multithreaded program
247 mirror the standard semantics for signals.
249 when a thread reads from a signalfd file descriptor,
250 it will read the signals that are directed to the thread
251 itself and the signals that are directed to the process
252 (i.e., the entire thread group).
253 (A thread will not be able to read signals that are directed
254 to other threads in the process.)
256 .SS epoll(7) semantics
257 If a process adds (via
259 a signalfd file descriptor to an
263 returns events only for signals sent to that process.
264 In particular, if the process then uses
266 to create a child process, then the child will be able to
268 signals that are sent to it using the signalfd file descriptor, but
272 indicate that the signalfd file descriptor is ready.
273 In this scenario, a possible workaround is that after the
275 the child process can close the signalfd file descriptor that it inherited
276 from the parent process and then create another signalfd file descriptor
277 and add it to the epoll instance.
278 Alternatively, the parent and the child could delay creating their
279 (separate) signalfd file descriptors and adding them to the
280 epoll instance until after the call to
285 returns a signalfd file descriptor;
286 this is either a new file descriptor (if
292 was a valid signalfd file descriptor.
293 On error, \-1 is returned and
295 is set to indicate the error.
301 file descriptor is not a valid file descriptor.
305 is not a valid signalfd file descriptor.
308 .\" argument is not equal to
309 .\" .IR sizeof(sigset_t) ;
314 or, in Linux 2.6.26 or earlier,
319 The per-process limit on the number of open file descriptors has been reached.
322 The system-wide limit on the total number of open files has been
326 Could not mount (internal) anonymous inode device.
329 There was insufficient memory to create a new signalfd file descriptor.
332 is available on Linux since kernel 2.6.22.
333 Working support is provided in glibc since version 2.8.
334 .\" signalfd() is in glibc 2.7, but reportedly does not build
337 system call (see NOTES) is available on Linux since kernel 2.6.27.
344 A process can create multiple signalfd file descriptors.
345 This makes it possible to accept different signals
346 on different file descriptors.
347 (This may be useful if monitoring the file descriptors using
352 the arrival of different signals will make different file descriptors ready.)
353 If a signal appears in the
355 of more than one of the file descriptors, then occurrences
356 of that signal can be read (once) from any one of the file descriptors.
364 are silently ignored.
366 The signal mask employed by a signalfd file descriptor can be viewed
367 via the entry for the corresponding file descriptor in the process's
368 .IR /proc/ pid /fdinfo
375 The signalfd mechanism can't be used to receive signals that
376 are synchronously generated, such as the
378 signal that results from accessing an invalid memory address
381 signal that results from an arithmetic error.
382 Such signals can be caught only via signal handler.
385 in normal usage one blocks the signals that will be accepted via
387 If spawning a child process to execute a helper program
388 (that does not need the signalfd file descriptor),
389 then, after the call to
391 you will normally want to unblock those signals before calling
393 so that the helper program can see any signals that it expects to see.
395 that this won't be possible in the case of a helper program spawned
396 behind the scenes by any library function that the program may call.
397 In such cases, one must fall back to using a traditional signal
398 handler that writes to a file descriptor monitored by
404 .SS C library/kernel differences
405 The underlying Linux system call requires an additional argument,
406 .IR "size_t sizemask" ,
407 which specifies the size of the
412 wrapper function does not include this argument,
413 since it provides the required value for the underlying system call.
415 There are two underlying Linux system calls:
419 The former system call does not implement a
422 The latter system call implements the
424 values described above.
425 Starting with glibc 2.9, the
427 wrapper function will use
429 where it is available.
431 In kernels before 2.6.25, the
435 fields are not filled in with the data accompanying a signal sent by
437 .\" The fix also was put into 2.6.24.5
439 The program below accepts the signals
443 via a signalfd file descriptor.
444 The program terminates after accepting a
447 The following shell session demonstrates the use of the program:
451 .RB "$" " ./signalfd_demo"
452 .BR "\(haC" " # Control\-C generates SIGINT"
456 \fB\(ha\e\fP # Control\-\e generates SIGQUIT
463 .\" SRC BEGIN (signalfd.c)
469 #include <sys/signalfd.h>
478 struct signalfd_siginfo fdsi;
481 sigaddset(&mask, SIGINT);
482 sigaddset(&mask, SIGQUIT);
484 /* Block signals so that they aren\(aqt handled
485 according to their default dispositions. */
487 if (sigprocmask(SIG_BLOCK, &mask, NULL) == \-1)
488 err(EXIT_FAILURE, "sigprocmask");
490 sfd = signalfd(\-1, &mask, 0);
492 err(EXIT_FAILURE, "signalfd");
495 s = read(sfd, &fdsi, sizeof(fdsi));
496 if (s != sizeof(fdsi))
497 err(EXIT_FAILURE, "read");
499 if (fdsi.ssi_signo == SIGINT) {
500 printf("Got SIGINT\en");
501 } else if (fdsi.ssi_signo == SIGQUIT) {
502 printf("Got SIGQUIT\en");
505 printf("Read unexpected signal\en");
519 .BR timerfd_create (2),