Norman Gaywood wrote:
I am running Buchan Milne's build of openldap-2.3.43-1.rhel5.x86_64 on a RedHat 5.2 system running kernel 2.6.18-92.1.6.el5. in a VMware instance.
This system runs as a master to 3 other syncrepl slaves. Very few queries are made against this system, it is simply a central place to direct updates to. Writes are infrequent, averaging 4-5 and hour. Databases are hdb.
This system was running openldap-servers-2.3.39-3.rhel5.x86_64 for several months until a few days ago when I did a update via yum pointing to http://staff.telkomsa.net/packages/rhel5/openldap/x86_64/
This system has been running without issues until last night. Then this appeared in the logs during deletion of a user account:
Jul 25 02:41:51 janus slapd[31075]: conn=7142 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 02:41:51 janus slapd[31075]: conn=7142 op=1 RESULT tag=107 err=80 text=DN index delete failed
Other accounts have been deleted before and after this event. Further attempts to delete this particular entry always fail with the same error.
In an attempt to fix this, I shutdown slapd, ran /usr/bin/slapd_db_recover in the /var/lib/ldap directory and restarted slapd.
Attempting to delete the entry after this produced:
Jul 25 14:20:14 janus slapd[15043]: conn=3 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 14:20:14 janus slapd[15043]: conn=3 op=1 RESULT tag=107 err=32 text=
Result code 32 indicates that the object does not exist in the DIT.
Have you added any new indexes previous to this? How did you upgrade your RPMs?
Further attempts return us to:
Jul 25 14:24:54 janus slapd[15043]: conn=19 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 14:24:54 janus slapd[15043]: conn=19 op=1 RESULT tag=107 err=80 text=DN index delete failed
Searching the list, I see similar problems mentioned in these threads:
http://www.openldap.org/lists/openldap-software/200801/msg00257.html http://www.openldap.org/lists/openldap-software/200802/msg00045.html
There did not seem to be any resolution to these however.