Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

[h.b.furuseth@usit.uio.no]

On 1/20/19 5:26 AM, Howard Chu wrote:
> Hallvard Breien Furuseth wrote:
>> On 1/20/19 4:48 AM, Hallvard Breien Furuseth wrote:
>>> On 1/20/19 2:14 AM, Howard Chu wrote:
>>>> This was the safest approach, considering that a config change could alter/remove context out
>>>> from under running threads otherwise.
>>>
>>> No, the safest approach is to fail the 2nd cn=config mod
>>> unless the user says it's OK to block the server.
> 
> How would the user say so?

An LDAP control.  Or the modify operation could modify an
operational attribute which which doesn't exist in LDAP, it just
changes the operation's behavior.

Or only accept cn=config mods after the connection has added
an ephemeral control entry which says how cn=config mods should
behave in that connection.  Maybe that's the least annoying way,
since there won't be any special cases for the use to cope with.

Either way, it sounds like there's no right answer for RE24's
default behavior, and the only fix there would involve a config
option which says which behavior to pick.
(It'd be nice to be able to say things like "it's OK to hang
if ldapi:// is the only listener", but I suppose then people
have a hundred other conditions which would be nice too.)

I don't like any of my own answers to this though.
I just dislike server hangs more.

>> Or fail the 1st cn=config mod too, if that's easier.
> 
> Huh? That op has already completed. The indexer is started as a background task after
> the mod op completes.

I meant fail when the operation is issued, but never mind.
That was silly, and cumbersome for the user to find out when
he can safely issue the next operation.


Either way,  diagnosticMessage "RTFM: back-mdb(5) about
olcDbIndex and slapd-config(5) about possible server hangs".

And we should document when cn=config mods can be dangerous
and how to use it safely without the users noticing.

There should in any case be a method to ask the server "is
cn=config very busy now, or is another cn=config mod safe?".
Like failing the operation if it is not, like I said first.