Process hierarchy on a DC?
Andreas Schneider
asn at samba.org
Sat Apr 29 06:05:30 UTC 2017
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 :)
More information about the samba-technical
mailing list