Process hierarchy on a DC?

[Jeremy Allison]

On Thu, Apr 27, 2017 at 08:31:17PM +0200, Ralph Böhme wrote:
> On Thu, Apr 27, 2017 at 09:23:48AM -0700, Jeremy Allison wrote:
> > On Thu, Apr 27, 2017 at 12:04:58PM +0200, vl--- via samba-technical wrote:
> > > Hi!
> > > 
> > > With current master 5701880655c8a82b6 I'm getting the following
> > > process hierarchy (omitting the duplicate children):
> > > 
> > > 24963 ?        Ss     0:00 bin/samba
> > > 24964 ?        S      0:00  \_ bin/samba
> > > 24969 ?        S      0:00 bin/samba
> > > 24971 ?        Ss     0:00  \_ /root/samba/bin/smbd -D --option=server role check:inhibit=yes --foreground
> > > 24991 ?        S      0:00      \_ /root/samba/bin/smbd -D --option=server role check:inhibit=yes --foreground
> > > 24979 ?        S      0:00 bin/samba
> > > 24981 ?        Ss     0:00  \_ /root/samba/bin/winbindd -D --option=server role check:inhibit=yes --foreground
> > > 24990 ?        S      0:00      \_ /root/samba/bin/winbindd -D --option=server role check:inhibit=yes --foreground
> > > 
> > > I think I remember that in the past this was all located under one
> > > "samba" process, now the winbind and smbd parents are themselves
> > > children of init. I could stop the DC with a single kill, now it's
> > > three.
> > > 
> > > Just curious: Why was this changed?
> > 
> > It's the tfork code. I'd bet good money on it :-).
> > 
> > samba_runcmd_send() which is used to invoke winbindd
> > calls tfork() directly.
> > 
> > This is a side effect I missed in my review of
> > the tfork code, but in my defense both Ralph
> > and Metze who were the authors missed it too :-).
> > 
> > Ralph, Metze, ball is in your court I think :-).
> 
> looking into it. Shall we revert 292e46ab12d8ec172c9d3b26330d8d6028a1d5a5 until
> I have worked out something to address this? Currently researching how to
> inherit process group and session and *not* become our own process group and
> session leader.

Much though I hate to revert, I think this might be a good case
for it temporarily.

> Sorry for any trouble this may have caused and thanks Jeremy for pinpointing
> this!

Well. I should have caught it in review, sorry. Thanks to
Volker for noticing this.