Hello,
Le 03/05/2023 à 18:37, Quanah Gibson-Mount a écrit :
Futhermore, can this explain the crashes/stops?
No. From the logs, something is telling slapd to stop, you need to figure out what that is.
I am returning here to provide an update on this matter long after our initial exchanges and in case it might be useful to someone. Our migration to OpenLDAP 2.5 having been delayed multiple times, I was unable to investigate this issue until now. I finally handled the migration today and encountered the same error as in 2023: when the slave server connected to the master server to initiate synchronization, the master server would shut down without any clear explanation.
As Stefan Kania noted in 2023 (many thanks to him), we had an issue with multiple DSNs in the LDAP database. I had dismissed this problem based on advice from Quanah Gibson-Mount without delving deeper into it at the time. Today, after reproducing the error, I decided to address this multiple DNS issue. We hadn't discussed a method to do this, but my improvised method seems to have worked:
service slapd stop slapcat | grep -vE '^(entryCSN|contextCSN): ' > /tmp/ldif rm -f /var/lib/ldap/*.mdb slapadd -q -l /tmp/ldif chown openldap: -R /var/lib/ldap/ service slapd start
I then reset the database of our secondary server from a new dump of the master server, and following that, the synchronization was functional and, most importantly, no longer caused the master server to crash!
Thank you again for the help received here, and I hope this testimony will be useful to someone.
Best regards,
P.S.: There must still be an underlying bug, as a crash is never a normal occurrence (an error message would have been more appropriate ;)). Apparently, syncprov does not like databases with multiple values in the contextCSN attribute (we had three in our case).