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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html