vanishing messaging context names

[Jeremy Allison]

On Wed, Mar 29, 2017 at 01:31:18PM +1300, Andrew Bartlett wrote:
> On Tue, 2017-03-28 at 15:42 -0700, Jeremy Allison wrote:
> > On Wed, Mar 29, 2017 at 10:53:04AM +1300, Andrew Bartlett wrote:
> > > 
> > > I agree.  I've been bitten by it before. 
> > > 
> > > In any case, here is a patch.  The result of irpc_add_name() is no
> > > longer removed by talloc_free(), but is removed when the stream or
> > > task
> > > is terminated.  In source3 this is left as-was, but it is safe
> > > because
> > > only the notify server registers a name.
> > > 
> > > Now we just need tests to show it stays around, that don't rely on
> > > side-effects of other tests and test test order.
> > 
> > Hmmm. I can see the point of it, but I think it's a band-aid
> > around the lack of proper handling of fork() inside the
> > source4 code.
> > 
> > If you look inside lib/util/server_id_db.c, there is already
> > server_id_db_reinit(), called in source3 from messaging_reinit(),
> > which is called from reinit_after_fork(), and *that* is
> > called inside every child created using fork() inside source3/
> > 
> > I think the proper fix is going to be doing the same thing
> > inside the bin/samba binary for forked tasks. Otherwise we
> > will forever be fighting this inside source4-forked children.
> > 
> > I'd rather bite the bullet and fix this properly for all
> > time now :-).
> 
> Patches welcome, but we have multiple messaging contexts in source4, so
> it isn't as simple.  In the meantime, I don't like DB or filesystem

After a fork all messaging contexts need to
be reset, otherwise you are guarenteed to have problems
like the one I'm tracking now.

> modification in a talloc destructor (see the earlier, rejected,
> proposal for a talloc_free_for_exit()), which is why I propose this
> patch.
> 
> To be clear, this part of a series to try and make multi-process LDAP
> sane, because I've had a number of our user say they are bleeding on
> this when they hook Zarafa (a mail server) up to Samba.

If we fix this properly in the process-model code (after we fork),
then we should be able to remove the problem from any other
services we later move to multi-process.