sigwait - differences between Linux & FreeBSD

[Stephen Hocking]

On Thu, Oct 8, 2009 at 10:38 PM, Matthias Andree <matthias.andree at gmx.de> wrote:
> Stephen Hocking schrieb:
>> Hi all,
>>
>> In my efforts to make the xrdp port more robust under FreeBSD, I have
>> discovered that sigwait (kind of an analogue to select(2), but for
>> signals rather than I/O) re-enables ignored signals in its list under
>> Linux, but not FreeBSD.
>
> If the application relies on sigwait() to wait for and extract an ignored signal
> (SIG_IGN), it is non-portable, as it expects non-POSIX semantics, and should be
> fixed by the upstream maintainer (I haven't checked that).
>
> Note: Linux has the same semantics, quoting its manual page (on Ubuntu 9.10 beta):
>
>       sigwait  suspends the calling thread until one of the signals in set is
>       delivered to the calling thread. It then stores the number of the  sig‐
>>      nal received in the location pointed to by sig and returns. The signals
>>      in set must be blocked and not ignored on entrance to sigwait.  If  the
>       delivered  signal has a signal handler function attached, that function
>       is not called.
>
>> The sesman daemon uses SIGCHLD to clean up after a session has exited. Under
>> Linux this works OK, under FreeSBD it doesn't.
>
> Not sure I understand. How can it clean up if it's not made aware of child's
> termination? Or do some Linux kernels behave in another way?

It appears as if the documentation does not match up with the reality
in Linux's case. That's what the empirical evidence suggests anyway.
The code does does a waitpid after receiving the SIGCHLD to determine
what child process has exited and then searches its list of sessions
looking for that particular pid, so as to tidy up.

I can to some degree understand that implementation of sigwait, as if
you state your intention to wait for a particular signal, that means
that you don't wish to ignore it.

>
> Setting SIGCHLD to SIG_IGN (default) means that the kernel will let go of the
> child processes as they exit, rather than turn them into zombies. You cannot
> wait() for them though.
>
>> I have worked around it in a very hackish manner (define a
>> dummy signal handler and enable it using signal, which means that the
>> sigwait call can then be unblocked by it), but am wondering if anyone
>> else has run across the same problem, and if so, if they fixed it in
>> an elegant manner. Also, does anyone know the correct semantics of
>> sigwait under this situation?
>
> That is not a hackish workaround, but one of the few safe ways to sigwait() for
> SIGCHLD. A version fixed thus should still work on Linux, so that fix should be
> made by xrdp upstream.
>
>
> The canonical reference would be the POSIX standard (IEEE Std 1003.1).
>
> 2008: http://www.opengroup.org/onlinepubs/9699919799/
>
> 2001, 2004 edition: http://www.opengroup.org/onlinepubs/000095399/
>
> The latter is also known as the Single Unix Specification v3 (SUSv3).

Thanks for the references.