Hi fellows
my OpenLDAP keeps on dying sporadically. Unfortunately it doesn't leave ANY trace of why it crashes. It stays alive for a while .... takes a couple of queries as expected ... and then suddenly it dies after another request. This could mean working perfectly for a day or working only for a couple of minutes before it crashes. The requests are all known to work (Dovecot auth and system PAM auth). At first I thought it could be related to newsyslog(8) ... I did some testing - unfortunately this doesn't change anything at all. It keeps on dying sporadically even if newsyslog is completely deactivated for the slapd(8) log file.
I experenced this behauviour since I first used OpenLDAP approximately 5 years ago. My OpenLDAP configurations have been changed many times and quite a lot over those 5 years. Unfortunately I was never able to figure out what the sudden crashes caused - so I wrote a supervisor script , which periodically checks if the slapd(8) is still running. If slapd(8) is not running, then my supervisor script starts it automatically again. Of course with every major change in the configuration of OpenLDAP, I also tried to debug this problem of the sudden crashes - but as I said: even with all debug levels activated - slapd(8) didn't want to share its root of the pain. This workaround was the only way I could use OpenLDAP at all over the past five years.
Two days ago I got to the point where my workaround came to its capacity boundary. The time between the slapd(8) crashes has become so little, so my script can't handle them anylonger. I would have two options now:
a) Fix my supervisor script, so it detects and starts slapd(8) even if the time between crashes is less than 3 sec. b) I ask for help in order to discover this mysterious cause of the crashes and FINALLY fix it FOREVER.
So this time I set my foot down and go for b). This is why I decided to contact you. The following link containes a more detailed debugging of the problem:
https://forums.freebsd.org/threads/openldap-slapd-dies-sporadically.47634/
And this is the current / latest configuration I deploy on my servers. Also, it doesn't make a difference whether I have monitoring activated or not. It keeps on dieing the same as before. The very same ocours to the "ldapab.schema" - it doesn't make a difference for the crashes to happen whether it is commented out or activated. Logging hapens through syslogd(8).
# ============================================================ #
#======================================# # slapd.conf # #======================================#
# LDAP Attribut Schema Definitions: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/ldapab.schema include /usr/local/etc/openldap/schema/mail.schema #include /usr/local/etc/openldap/schema/qouta.schema
# Logging loglevel 256 # If "logfile" is activated, then newsyslog must restart slapd after rotation #logfile /var/log/slapd.log
# Important Files pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# Allow LDAPv2 client connections. This is required for iOS suppoprt via SSL. #allow bind_v2
# Time limits #idletimeout 0 #writetimeout 0 #timelimit 3600
# Dynamic Modules: modulepath /usr/local/libexec/openldap moduleload back_mdb moduleload back_monitor
# Access from 127.0.0.1 without encryption access to dn.subtree="dc=MyDomain,dc=local" by peername.ip=127.0.0.1 write by * none break
# Access from other than 127.0.0.1 requires TLS # encryption with min. 128 bit encryption access to dn.subtree="dc=MyDomain,dc=local" by ssf=128 write by * none
# TLS-Certificate TLSCertificateFile /etc/ssl/PKI/CA/Signing-CA/Certs/WM-01.MyDomain.Local.crt TLSCertificateKeyFile /etc/ssl/PKI/CA/Signing-CA/Private/WM-01.MyDomain.Local.key TLSVerifyClient allow
# Restrict write access for password attributes to root user only by dn="uid=dovecot,ou=systemuser,ou=mail,dc=MyDomain,dc=Local" access to attrs=userPassword by self write by anonymous auth by * none
# All the other atributes can be read by everyone else access to * by * read
# ================================== # # Internal Monitoring # # ================================== #
# DB type database monitor
# Name of Administrator rootdn "cn=monitoring,cn=Monitor"
# Password of Administrators rootpw {SSHA}SomeHash
# ACL for moitoring access to dn.subtree="cn=Monitor" by dn.exact="cn=admin,dc=MyDomain,dc=local" write by peername.ip=127.0.0.1 read by users read by * none
# ================================== # # Lightning Memory-Mapped Database # # ================================== #
# Datenbanktyp database mdb
# DB location on FS directory /var/db/openldap-data
# Datenbank-Pfad suffix "dc=MyDomain,dc=local"
# Name of Administrator rootdn "cn=admin,dc=MyDomain,dc=local"
# Password of Administrators rootpw {SSHA}SomeHash
# Max size of DB in Byte [ 5368709120 Byte => 5 GB ] maxsize 5368709120
# Index search related attributes index objectClass eq index uid eq index uidNumber eq index uniqueMember eq index gidNumber eq index cn eq index memberUid eq index mailAccountStatus eq index mailAddress eq index associatedDomain eq
# ============================================================= #
I compiled OpenLDAP from FreeBSD ports with following options: - DYNAMIC_BACKENDS - MDB - PPOLICY - SYNCPROV - TCP_WRAPPERS
Please let me know what kind of further information I could deliver to you in order to detect the root of the problem. Thank you
Best regards Leander