Process hierarchy on a DC?

[Andreas Schneider]

On Friday, 28 April 2017 13:11:30 CEST Stefan Metzmacher via samba-technical 
wrote:
> Am 28.04.2017 um 12:06 schrieb Ralph Böhme:
> > On Thu, Apr 27, 2017 at 02:39:21PM -0700, Jeremy Allison wrote:
> >> Much though I hate to revert, I think this might be a good case
> >> for it temporarily.
> > 
> > two patchsets attached:
> > 
> > 1) revert the use of tfork in samba_runcmd_send(). This restores the
> > process hierarchy and stopping samba by sending a single SIGTERM
> 
> Please add a large explaination to the commit message, basically a summary
> of this mail thread.
> 
> > If this process hierarchy is a problem then I guess we need two functions
> > in the future:
> > 
> > - apply the revert and rename samba_runcmd_send (and the callers) to
> > something> 
> >   like samba_runchld_send()
> > 
> > - re-add a samba_runcmd_send() that uses tfork
> > 
> > samba_runchld_send() would be used for starting long lived processes where
> > you care about the process hierarchy, preserving the problematic
> > behaviour that you have to correctly handle SIGCHLD yourself. So just the
> > existing behaviour.
> I'd name it samba_start_child_send().
> 
> Here I'd still like to deliver the exit status of the process via a pipe,
> maybe just doing a double fork, basically skipping the first child that
> directly exists.
> The main process would still call waitpid() after getting the exit status
> from the pipe, to avoid zombies, but the result of waitpid() will be
> ignored.
> 
> > samba_runcmd_send() would be used for starting short lived processes or
> > when you just don't care about the process hierarchy and you wan't to be
> > sure that the command you run doesn't generate a SIGCHLD
> 
> And samba_run_command_send() which would be what we currently have in
> master.
> 
> Please note that some current callers of samba_runcmd_send() would want
> the samba_run_command_send() and some samba_start_child_send().

And please document both using doxygen :)