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

[Volker Lendecke]

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 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. 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).

Regards,

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de