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.