Hi, I am testing OpenLDAP-2.4.44 on OpenIndiana-Hipster. I have configured two back-mdb databases.For some strange reason a data.mdb and a bdb logfile is created.
openldap openldap 45441024 Juli 17 16:45 data.mdb openldap openldap 8192 Juli 17 16:57 lock.mdb root root 10485760 Juli 17 16:57 log.0000000001
After a restart slapd cannot read the data.mdb anymore.
-Dieter
-- Dieter Klünter | Directory Service http://sys4.de 53°37'09,95"N 10°08'02,42"E
--On Wednesday, July 17, 2019 6:46 PM +0200 Dieter Klünter dieter@dkluenter.de wrote:
Hi, I am testing OpenLDAP-2.4.44 on OpenIndiana-Hipster. I have configured two back-mdb databases.For some strange reason a data.mdb and a bdb logfile is created.
openldap openldap 45441024 Juli 17 16:45 data.mdb openldap openldap 8192 Juli 17 16:57 lock.mdb root root 10485760 Juli 17 16:57 log.0000000001
A couple of things... The log file is created by root? Sounds like some process (init script, etc) is running BDB's db_recover command? It could also be helpful to see your configuration. Are the backends static or dynamic? Why are you using such an old release? ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com writes:
--On Wednesday, July 17, 2019 6:46 PM +0200 Dieter Klünter dieter@dkluenter.de wrote:
Hi, I am testing OpenLDAP-2.4.44 on OpenIndiana-Hipster. I have configured two back-mdb databases.For some strange reason a data.mdb and a bdb logfile is created.
openldap openldap 45441024 Juli 17 16:45 data.mdb openldap openldap 8192 Juli 17 16:57 lock.mdb root root 10485760 Juli 17 16:57 log.0000000001
A couple of things... The log file is created by root? Sounds like some process (init script, etc) is running BDB's db_recover command? It could also be helpful to see your configuration. Are the backends static or dynamic? Why are you using such an old release? ;)
It seems the log file is created by root. The init script contains some db_recover lines.
cd ${VARDATADIR} /usr/bin/db_recover >/dev/null 2>&1 exec ${SLAPD} 2>&1
You know that I prefer actual releases but the maintainer sticks to mature packages :-) I still miss some devel libs and tools to build my own package. All backends are static built-in, there are no dynamic modules and backends.
Thank you for your hint on db_recover.
-Dieter
-- Dieter Klünter | Directory Service http://sys4.de 53°37'09,95"N 10°08'02,42"E
--On Wednesday, July 17, 2019 7:34 PM +0200 Dieter Klünter dieter@dkluenter.de wrote:
You know that I prefer actual releases but the maintainer sticks to mature packages :-)
I'm not sure what would qualify 2.4.44 as "mature" vs 2.4.47... They are incremental patch releases. More importantly, since you're testing with back-mdb, serious, significant fixes have been made to back-mdb since the 2.4.44 release, like:
Fixed slapd-mdb double free with size zero paged result (ITS#8655) Fixed slapd-mdb with an optimization for long lived read transactions (ITS#8226)
And some more important fixes coming out with 2.4.48, like:
Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) Fixed slapd-mdb index cleanup with cn=config (ITS#8472)
I.e., they're only asking for trouble by sticking with a release that's over 3 years old. I'll never understand these corporate policies that seem designed to ensure the maximum amount of pain and problems. :P
Thank you for your hint on db_recover.
:)
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org