[Q] what to do when waitpid() returns ECHILD under signal(SIGCHLD, SIG_IGN)?

Somebody I met last week in Japan reported that the socks client
he uses to cross the firewall to connect to git:// port from his
company environment seems to do signal(SIGCHLD, SIG_IGN) before
spawning git.  When "git clone" is invoked this way, we get a
mysterious failure.

I can reproduce the problem without using funny socks client
like this:

        : gitster; trap '' SIGCHLD
        : gitster; git clone git://git.kernel.org/pub/scm/git/git.git/ foo.git
        error: waitpid failed (No child processes)
        fetch-pack from 'git://git.kernel.org/pub/scm/git/git.git/' failed.
        : gitster; ls foo.git
        ls: foo.git: No such file or directory

We could work this around by having signal(SIGCHLD, SIG_DFL)
upfront in git.c::main(), but I am wondering what the standard
practice for programs that use waitpid() call.  Do they protect
themselves from this in order to reliably obtain child exit
status?  Or do they simply consider it is a user error to run a
program that use waitpid() with SIGCHLD ignored?

http://www.opengroup.org/onlinepubs/009695399/functions/waitpid.html

explicitly says this is an expected behaviour, so barfing upon
ECHILD sounds like a bug on our part.

On Mon, 19 Jun 2006, Junio C Hamano wrote:

Somebody I met last week in Japan reported that the socks client
he uses to cross the firewall to connect to git:// port from his
company environment seems to do signal(SIGCHLD, SIG_IGN) before
spawning git.

Ok, that sounds pretty broken of it.

We could work this around by having signal(SIGCHLD, SIG_DFL)
upfront in git.c::main(), but I am wondering what the standard
practice for programs that use waitpid() call.

We need the status return, so failing on getting ECHILD is absolutely the 
right thing to do, because it implies that we don't know what the status 
could have been.

So we need to reset SIGCHLD back to SIG_DFL (or catch it explicitly).

Whether we want to do that in the main() routine or when we actually do 
the fork() or whatever is a different issue.

		Linus

Junio C Hamano wrote:

Somebody I met last week in Japan reported that the socks client
he uses to cross the firewall to connect to git:// port from his
company environment seems to do signal(SIGCHLD, SIG_IGN) before
spawning git.

Similar problems occasionally happen with SIGPIPE.  There are apps[1]
that spawn processes with SIGPIPE set to SIG_IGN giving unexpected
results, i.e. child processes that still try to produce output
(getting EPIPE on every printf, but who checks printf errors?) even
if the pipe-reader (e.g. their parent) is long gone.

Ciao, ET.

[1] i.e. KDE had this bug - don't know if it's still there.