At this point I've found a DN that refuses to delete, and can 100% consistently:

ldapdelete -xZZH ldap://localhost/ -D "cn=identityThatCanWrite" -f /tmp/baddn -w password ldap_delete: Internal (implementation specific) error (80) additional info: DN index delete failed

The theory came up that it could be a perms issue, so I attached truss to slapd while I reproduced with ldapdelete(1). I checked with:

$ grep Err /tmp/trussout | cut -d# -f2 | sort | uniq -c 21 11 EAGAIN 2 131 ECONNRESET 3 134 ENOTCONN 7 25 ENOTTY

so no EACCES, so I doubt slapd is running into perms issues. (I'm also seeing this on batches of multiple deletes -- perms doesn't explain seven deletes working and the eighth failing.)

Any other ideas? I kind of feel like it's a bdb cache thing, because I think I've influenced it by searching for the DN in question first (which I assume does some sort of cache refresh/hit).

On Mon, 28 Jan 2008, Aaron Richton wrote:

My syncrepl provider seems to be missing updates following an upgrade to 2.3.40. While I was trying to push them through this morning, I got an odd message:

Jan 28 08:46:19 slapd[12685]: [ID 588225 local4.debug] conn=234174 op=2 RESULT tag=107 err=80 text=DN index delete failed

Is there anything I can do about this, or maybe just an idea of where to look or what information to take down for next time? I was going to try and file an ITS for tracking or maybe to try and walk some structures, but the DN in question deleted without incident about ten minutes later.