Revised signalfd man-page

From: Michael Kerrisk
Date: Thu Sep 27 2007 - 08:21:50 EST


Below is the current signalfd man-page. Could you please review to see
whether the man page describes the intended implementation, and especially
look at a few questions embedded in the page (look for "Davide").



.\" Copyright (C) 2007 Michael Kerrisk <mtk.manpages@xxxxxxxxx>
.\" starting from a version by Davide Libenzi <davidel@xxxxxxxxxxxxxxx>
.\" This program is free software; you can redistribute it and/or modify
.\" it under the terms of the GNU General Public License as published by
.\" the Free Software Foundation; either version 2 of the License, or
.\" (at your option) any later version.
.\" This program is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" GNU General Public License for more details.
.\" You should have received a copy of the GNU General Public License
.\" along with this program; if not, write to the Free Software
.\" Foundation, Inc., 59 Temple Place, Suite 330, Boston,
.\" MA 02111-1307 USA
.TH SIGNALFD 2 2007-09-27 Linux "Linux Programmer's Manual"
signalfd \- create a file descriptor for accepting signals
.\" FIXME . This header file may well change
.\" FIXME . Probably _GNU_SOURCE will be required
.\" FIXME . May require: Link with \fI\-lrt\f
.B #include <sys/signalfd.h>
.BI "int signalfd(int " fd ", const sigset_t *" mask );
.\" Almost certainly the glibc wrapper will hide this argument:
.\" ", size_t " sizemask
.BR signalfd (2)
creates a file descriptor that can be used to accept signals
targeted at the caller.
This provides an alternative to the use of a signal handler or
.BR sigwaitinfo (2),
and has the advantage that the file descriptor may be monitored by
.BR select (2),
.BR poll (2),
.BR epoll (7).
.I mask
argument specifies the set of signals that the caller
wishes to accept via the file descriptor.
This argument is a signal set whose contents can be initialized
using the macros described in
.BR sigsetops (3).
Normally, the set of signals to be received via the
file descriptor should be blocked using
.BR sigprocmask (2),
to prevent the signals being handled according to their default
It is not possible to receive
signals via a signalfd file descriptor;
these signals are silently ignored if specified in
.IR mask .

If the
.I fd
argument is \-1,
then the call creates a new file descriptor and associates the
signal set specified in
.I mask
with that descriptor.
.I fd
is not \-1,
then it must specify a valid existing signalfd file descriptor, and
.I mask
is used to replace the signal set associated with that descriptor.

.BR signalfd (2)
returns a file descriptor that supports the following operations:
.BR read (2)
If one or more of the signals specified in
.I mask
is pending for the process, then the buffer supplied to
.BR read (2)
is used to return one or more
.I signalfd_siginfo
structures (see below) that describe the signals.
.BR read (2)
returns information for as many signals as are pending and will
fit in the supplied buffer.
The buffer must be at least
.I "sizeof(struct signalfd_siginfo)"
The return value of the
.BR read (2)
is the total number of bytes read.
As a consequence of the
.BR read (2),
the signals are consumed,
so that they are no longer pending for the process
(i.e., will not be caught by signal handlers,
and cannot be accepted using
.BR sigwaitinfo (2)).
If none of the signals in
.I mask
is pending for the process, then the
.BR read (2)
either blocks until one of the signals in
.I mask
is generated for the process,
or fails with the error
if the file descriptor has been made non-blocking
(via the use of the
.BR fcntl (2)
operation to set the

.\" FIXME Davide, what does the following mean? How (in userspace
.\" terms) does a sighand structure become orphaned?
.BR read (2)
call can also return 0,
in case the sighand structure to which the signalfd was attached,
has been orphaned.
.BR poll "(2), " select "(2) (and similar)"
The file descriptor is readable
.BR select (2)
.I readfds
argument; the
.BR poll (2)
if one or more of the signals in
.I mask
is pending for the process.
The signalfd file descriptor also supports the other file-descriptor
multiplexing APIs:
.BR pselect (2),
.BR ppoll (2),
.BR epoll (7).
.BR close (2)
When the file descriptor is no longer required it should be closed.
When all file descriptors associated with the same signalfd object
have been closed, the resources for object are freed by the kernel.
.SS The signalfd_siginfo structure
The format of the
.I signalfd_siginfo
structure(s) returned by
.BR read (2)s
from a signalfd file descriptor is as follows:
.in +0.5i

.\" FIXME Davide, a question: why rename these fields to be
.\" different from their siginfo_t counterparts? At the very least,
.\" it would have been nicer to use the same names with prefixes
.\" such as (say) "fdsi_" (thus, e.g., fdsi_signo); that would have
.\" made grepping both kernel and userland source code easier
.\" (e.g, to find instances of "si_signo" in a siginfo_t or a
.\" signalfd_siginfo structure), and also would have avoided
.\" weirdnesses like trimming "errno" down to err.
struct signalfd_siginfo { /* Analog in siginfo_t */
uint32_t signo; /* si_signo */
int32_t err; /* si_errno */
int32_t code; /* si_code */
uint32_t pid; /* si_pid */
uint32_t uid; /* si_uid */
int32_t fd; /* si_fd */
uint32_t tid; /* si_tid */
uint32_t band; /* si_band */
uint32_t overrun; /* si_overrun */
uint32_t trapno; /* si_trapno */
.\" trapno is unused on most (all?) arches?
int32_t status; /* si_status */
int32_t svint; /* si_int */
uint64_t svptr; /* si_ptr */
uint64_t utime; /* si_utime */
uint64_t stime; /* si_stime */
uint64_t addr; /* si_addr */
uint28_t pad[\fIX\fP]; /* Pad size to 128 bytes (allow space
additional fields in the future) */

As indicated in the comments, each of the fields in this structure
is analogous to a similarly named field in the
.I siginfo_t
.I siginfo_t
structure is described in
.BR sigaction (2).
Not all fields in the returned
.I signalfd_siginfo
structure will be valid for a specific signal;
the set of valid fields can be determined from the value returned in the
.I code
This field is the analog of the
.I siginfo_t
.I si_code
field; see
.BR sigaction (2)
for details.
.SS fork(2) semantics
After a
.BR fork (2),
the child inherits a copy of the signalfd file descriptor.
The file descriptor refers to the same underlying
file object as the corresponding descriptor in the parent,
.BR read (2)s
in the child will return information about signals generated
for the parent
(the process that created the object using
.BR signalfd (2)).
.SS execve(2) semantics
.\" Davide, what are the intended semantics after an execve()?
.\" As far as I can work out, after an execve() the file descriptor
.\" is still available, but reads from it always return 0, even if:
.\" a) there were signals pending before the execve().
.\" However, sigpending() shows the signal as pending,
.\" and the signal can be accepted using sigwaitinfo().
.\" b) we generate the signal after the exec.
.\" Is this intended behavior (the "orphaned sighand" condition
.\" described above?)? Is it a bug?
.SS Thread semantics
.\" FIXME Davide, a signal can be directed to the process as
.\" a whole, or to a particular thread. What are the intended
.\" semantics for signalfd()? If a thread calls signalfd(),
.\" does the resulting file descriptor return just those
.\" signals directed to [the thread and the process as a whole],
.\" or will it also receive signals that are targeted at
.\" other threads in the process?
On success,
.BR signalfd ()
returns a signalfd file descriptor;
this is either a new file descriptor (if
.I fd
was \-1), or
.I fd
.I fd
was a valid signalfd file descriptor.
On error, \-1 is returned and
.I errno
is set to indicate the error.
.I fd
file descriptor is not a valid file descriptor.
.I fd
is not a valid signalfd file descriptor.
.\" or the
.\" .I sizemask
.\" argument is not equal to
.\" .IR sizeof(sigset_t) ;
The per-process limit of open file descriptors has been reached.
The system-wide limit on the total number of open files has been
Could not mount (internal) anonymous i-node device.
There was insufficient memory to create a new signalfd file descriptor.
.BR signalfd (2)
is available on Linux since kernel 2.6.22.
.\" FIXME . check later to see when glibc support is provided
As at September 2007 (glibc 2.6), the details of the glibc interface
have not been finalized, so that, for example,
the eventual header file may be different from that shown above.
.\" FIXME The wrapper will almost certainly hide the sizemask
.\" argument, just as with pselect() and ppoll().
.BR signalfd (2)
is Linux specific.
The underlying Linux system call requires a third argument,
.IR "size_t sizemask" ,
which specifies the size of the
.I mask
The glibc
.BR signalfd ()
wrapper function provides the required value for this argument.

.\" FIXME Davide, are all of the details in the following
.\" paragraph correct?
A process can create multiple signalfd file descriptors.
This makes it possible to accept different signals
on different file descriptors.
(This may be useful if monitoring the file descriptors using
.BR select (2),
.BR poll (2),
.BR epoll (7):
the arrival of different signals will make different descriptors ready.)
If a signal appears in the
.I mask
of more than one of the file descriptors, then occurrences
of that signal can be read (once) from any one of the descriptors.
The program below accepts the signals
via a signalfd file descriptor.
The program terminates after accepting a
The following shell session demonstrates the use of the program:
.in +0.5i

$ ./signalfd_demo
^C # Control\-C generates SIGINT
^\\ # Control\-\\ generates SIGQUIT

.\" FIXME . Check later what header file glibc uses for signalfd
.\" FIXME . Probably glibc will require _GNU_SOURCE to be set
.\" The commented out code here is what we currently need until
.\" the required stuff is in glibc
.\" #define _GNU_SOURCE
.\" #include <sys/syscall.h>
.\" #include <unistd.h>
.\" #include <stdint.h>
.\" #include <signal.h>
.\" #if defined(__i386__)
.\" #define __NR_eventfd 323
.\" #endif
.\" struct signalfd_siginfo {
.\" uint32_t signo; /* si_signo */
.\" int32_t err; /* si_errno */
.\" int32_t code; /* si_code */
.\" uint32_t pid; /* si_pid */
.\" uint32_t uid; /* si_uid */
.\" int32_t fd; /* si_fd */
.\" uint32_t tid; /* si_fd */
.\" uint32_t band; /* si_band */
.\" uint32_t overrun; /* si_overrun */
.\" uint32_t trapno; /* si_trapno */
.\" int32_t status; /* si_status */
.\" int32_t svint; /* si_int */
.\" uint64_t svptr; /* si_ptr */
.\" uint64_t utime; /* si_utime */
.\" uint64_t stime; /* si_stime */
.\" uint64_t addr; /* si_addr */
.\" uint8_t __pad[48];
.\"static int
.\"signalfd(int fd, sigset_t const *mask)
.\"#define SIZEOF_SIG (_NSIG / 8)
.\"#define SIZEOF_SIGSET (SIZEOF_SIG > sizeof(sigset_t) ? \
.\" sizeof(sigset_t): SIZEOF_SIG)
.\" return syscall(__NR_signalfd, fd, mask, SIZEOF_SIGSET);
#include <sys/signalfd.h> /* May yet change for glibc */
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)

main(int argc, char *argv[])
sigset_t mask;
int sfd;
struct signalfd_siginfo fdsi;
ssize_t s;

sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);

/* Block signals so that they aren't handled
according to their default dispositions */

if (sigprocmask(SIG_BLOCK, &mask, NULL) == \-1)

sfd = signalfd(\-1, &mask);
if (sfd == \-1)

for (;;) {
s = read(sfd, &fdsi, sizeof(struct signalfd_siginfo));
if (s != sizeof(struct signalfd_siginfo))

if (fdsi.signo == SIGINT) {
printf("Got SIGINT\\n");
} else if (fdsi.signo == SIGQUIT) {
printf("Got SIGQUIT\\n");
} else {
printf("Read unexpected signal\\n");
.BR eventfd (2),
.BR poll (2),
.BR read (2),
.BR select (2),
.BR signalfd (2),
.BR sigaction (2),
.BR sigprocmask (2),
.BR sigwaitinfo (2),
.BR timerfd (2),
.BR sigsetops (3),
.BR epoll (7),
.BR signal (7)
.\" FIXME add SEE ALSO from signal.7, signal.2, sigwaitinfo.2,
.\" sigaction.2 to this page
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at