sigwait - differences between Linux & FreeBSD

Matthias Andree matthias.andree at gmx.de
Thu Oct 8 12:05:00 UTC 2009


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?

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).

HTH


More information about the freebsd-ports mailing list