Replace signals!

Posted Jan 10, 2022 3:06 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: Replace signals! by ibukanov
Parent article: VSTATUS, with or without SIGINFO

Could you please elaborate? I'm looking through the man page but I don't see any obvious gotchas there...

Replace signals!

Posted Jan 10, 2022 9:22 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (2 responses)

From the man page:

As described above, in normal usage one blocks the signals that will be accepted via signalfd(). If spawning a child process to execute a helper program (that does not need the signalfd file descriptor), then, after the call to fork(2), you will normally want to unblock those signals before calling execve(2), so that the helper program can see any signals that it expects to see. Be aware, however, that this won't be possible in the case of a helper program spawned behind the scenes by any library function that the program may call. In such cases, one must fall back to using a traditional signal handler that writes to a file descriptor monitored by select(2), poll(2), or epoll(7).

Surely if one controls the code and does not use libraries that executes processes it is fine. But it easy to forget about that. So in one code I just used a signal handler and pipe. As a bonus the code stays compatible with BSD. What is puzzling is that in all those years since signalfd were added no flag were added to reset blocked signals on exec.

Replace signals!

Posted Jan 10, 2022 19:25 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

To be fair, that exact same problem applies to pselect, which is POSIX-standardized and supposedly the Right Way to do this.

I'm not really a fan of libraries randomly forking off temporary processes without the application code's knowledge or consent, to be honest. Sure, if a library is specifically designed to do something like implement a process pool, I suppose it's unavoidable, but if you're just forking off a process because you can, then maybe don't do that.

Replace signals!

Posted Jan 11, 2022 11:23 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

With various sandboxing forking an extrenal process or even just executing another copy of the application becomes a common practice.

As for pselect if one writes to a pipe in the signal handler, then one does not need that. I wish that somebody would come up with a flag or something not to keep signals blocked across exec similarly to noexec flags to file descriptors, but I guess that writing to a pipe from a signal handler is so common knowledge that nobody bothered.