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

Andrew Bartlett abartlet at samba.org
Tue Mar 3 01:03:18 MST 2015

On Tue, 2015-03-03 at 07:41 +0100, Volker Lendecke wrote:
> On Tue, Mar 03, 2015 at 02:08:45PM +1300, Andrew Bartlett wrote:
> > 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 for the explanation, that makes sense. We don't have that
> exact pattern in source3/smbd at this point yet, so smbd is fine at
> this point. 

I agree.  Thanks for taking the time to think about it.

> I think I'd do it a bit differently though long-term.
> I'm not sure I like the additional resource usage from using a pipe
> per child. In smbd, we can easily have 5.000 and more children. That's
> 5.000 additional fd's in the parent that we have to listen for and that
> make fork more expensive. 

A very good point.

> What about centralizing the waitpid(-1) code
> somewhere close to tevent and do a central monitor_child_send/recv pair
> that "only" runs in memory without involving other kernel resources?
> We might maintain a global list of tevent_reqs waiting for children to
> exit. Whenever we do the central waitpid(-1) we walk this list (or a
> smarter data structure) and fire the corresponding tevent_req(s).

That certainly seems like a smart way to do it.  tevent could issue
events for child exits in very much the same way it issues events for

Thanks for thinking about this!

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