vanishing messaging context names

[Andrew Bartlett]

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

Thanks,

Andrew Bartlett