https://bugs.openldap.org/show_bug.cgi?id=9378
--- Comment #27 from Howard Chu hyc@openldap.org --- (In reply to stefan.bruens from comment #26)
(In reply to Howard Chu from comment #25)
(In reply to stefan.bruens from comment #22)
Is there any way to query at runtime if the env uses robust mutexes? (Runtime is required, as we liblmdb is dynamically linked.)
No. Nor is there any reason to query this, since the application shouldn't care either way. Especially for programs like baloo_file, which start up periodically, do some work, and then exit - the lockfile becomes irrelevant when the last process opening the env closes it, so any potentially stale locks go away by themselves anyway.
Your understanding here seems to be quite incorrect. baloo_file is started with the session, and keeps running until the session ends. Only the extractor process is spawned on demand.
Then it's even more stupid, because the extractor is deleting the lockfile with full knowledge that the process that spawned it is still active. Regardless of any particular documentation version, deleting the lockfile of a DB that you know full well is open in more than one process is stupid.
There may be many processes which also read the DB, and there is also another helper process which runs for the whole session duration. Other processes (e.g. dolphin) also keep the env open while the process is running. These process open read transactions just for very short durations, but nevertheless may crash (last but not least because some users think it is a good idea to SIGKILL random processes). Btw, apparently there is no API to query stale readers in a programmatically useful way, and not way to query active readers at all.
https://git.openldap.org/openldap/openldap/-/blob/mdb.RE/0.9/libraries/liblm...
There's nothing useful you can do with a list of stale readers, so the only API you need is one which clears them. Which is what is provided. It's debatable whether you can programmatically do anything useful with a list of active readers. You can always provide a FILE* handle to a socket if you really want it.