File descriptor from `signalfd(2)` is never ready to read

Question

I have a fairly big application under care. As part of its job it spawns some child processes and needs to monitor their state (running, crashed).

Child process deaths were detected by setting signal handler for SIGCHLD using signal(2). Some time ago I migrated it to signalfd(2). What I did was simple:

1. removed the signal handler for SIGCHLD
2. blocked SIGCHLD and created a signalfd(2) to capture SIGCHLD

My problem is that the file descriptor I created does not seem to capture SIGCHLD. However, if I ignore the return value of read(2) call on that descriptor and call waitpid(-1, &status, WNOHANG) I can obtain the information about exited child processes. So it looks like the notification is delivered but my signalfd(2) descriptor just ignores it.

I made sure to have exactly one place in the program where read(2) is called on the signalfd(2) descriptor, exactly one place where waitpid(2) is called, and exactly one place were the signal handling is set up.

The setup code looks like this:

sigset_t mask;
sigemptyset(&mask);
sigaddset(&mask, SIGCHLD);

sigprocmask(SIG_BLOCK, &mask, nullptr);

int signal_fd = signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC);
if (signal_fd == -1) {
    /* log failure and exit */
} else {
    /* log success */
}

The reading code looks like this:

signalfd_siginfo info;
memset(&info, 0, sizeof(info));

if (read(signal_fd, &info, sizeof(info)) == -1) {
    /*
     * Log failure and return.
     * The file descriptor *always* returns EAGAIN, even in
     * presence of dead child processes.
     */
    return;
}

if (info.ssi_signo == SIGCHLD) {
    int status = 0;
    int child = waitpid(-1, &status, WNOHANG);

    /*
     * Process result of waitpid(2). The call is successful even if
     * the read of signalfd above returned an error.
     */
}

What am I doing wrong?

Edit: The problem is that read(2) fails with EAGAIN even if there are dead child processes ready to be waitpid(2)-ed, which means that a SIGCHLD must have been delivered to my master process. I know that read(2) may return EAGAIN for non-blocking file descriptors and the code accounts for that.

Answer 1

When migrating from signal handling based on signal(2) or sigaction(2) to signalfd(2) you change the way you receive signals. The old way leaves the signals unblocked, the new one needs them blocked.

If you have some regions of code in which you do not want to be disturbed by signals you need to block them:

sigset_t mask;
sigemptyset(&mask);
sigaddset(&mask, SIGFOO);
pthread_sigmask(SIG_BLOCK, &mask, nullptr);

{
    /* not-to-be-disturbed code here */
}

This requires that you later unblock them, because otherwise signal(2) or sigaction(2) will not be able to pick them up.

{
    /* not-to-be-disturbed code here */
}

pthread_sigmask(SIG_UNBLOCK, &mask, nullptr);

However, for signalfd(2) the signals must stay blocked. If you have a long neglected code path that you rarely look at and it follows the old way ie, blocks and unblocks some signals, it may trash your signal-reading file descriptor you got from signalfd(2).

TL;DR Vet your code for any calls to signal(2), sigaction(2), pthread_sigmask(2) etc. when migrating to signalfd(2) to check if you did not forget about some codepath that messes with the signal mask.

(Two and a half years later may be a bit late, but maybe the answer will help someone.)

Answer 2

Your read(2) returns EAGAIN because you opened the file in non-blocking mode with signalfd(..., SFD_NONBLOCK | ...) (SFD_NONBLOCK is the same as O_NONBLOCK).

Don't open or set file descriptors to non-blocking mode if you want to do blocking reads on them.