[PATCH] Handle SIGCHLD better in process_standard, remove process_{onefork,prefork}

Andrew Bartlett abartlet at samba.org
Mon Mar 2 18:08:45 MST 2015


On Mon, 2015-03-02 at 16:58 -0800, Jeremy Allison wrote:
> On Tue, Mar 03, 2015 at 01:05:20PM +1300, Andrew Bartlett wrote:
> > 
> > The difference is that this code knows what the PID is for waitpid(),
> > rather than using a PID of -1: 	while ((pid = sys_waitpid(-1, &status,
> > WNOHANG)) > 0) {
> > 		bool unclean_shutdown = False;
> > 
> > The issue with waitpid() of -1, as I understand it, is that no other
> > waitpid (expecting a specific pid) can be called in that codebase,
> > because this one will preempt the more specific call, say in
> > samba_runcmd_recv(). 
> 
> The advantage to using waitpid(-1...WNOHANG) in this
> case is it also reaps zombies that we might not have
> been expecting.
> 
> Now we should always know about our children, and
> catch them when they terminate - but in the long and
> glorious history of Samba there might have been
> occassions where we weren't so dilligent, and leaked
> zombies like a bad episode of "The Walking Dead".
> 
> Current code stops that from happening again, should
> (god forbid :-) we make another mistake :-).

The issue is that this means we can't ever correctly report the error
code of a child that we 'unexpectedly' (ie intentionally, but not from
here) run, except when we use system().  

We don't use samba_runcmd_recv() in source3, but this all started
because in source4, I couldn't work out why our really badly broken
samba_kcc tool was always 'running successfully'.  It turned out that
when we tried to waitpid() on the already reaped child - in that case by
setting SIGCHLD to SIGING, we declared that to always mean
'success' (being assumed to be better than always failure). 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the samba-technical mailing list