[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
signals. 

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