On Thu, Nov 17, 2011 at 11:47 PM, Howard Chu hyc@symas.com wrote:

Jeffrey Crawford wrote:

...

On Thu, Nov 17, 2011 at 9:21 PM, Howard Chuhyc@symas.com  wrote:

...

Jeffrey Crawford wrote:

...

On Thu, Nov 17, 2011 at 5:50 PM, Howard Chuhyc@symas.com    wrote:

...

There ought to be other error messages in your log, immediately preceding

...

...

the one you quoted. Post those too.

...

There really isn't much there but here is an example really not much around it: (I've modified the usernames only)

Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 DEL dn="uid=user1,ou=people,dc=ucsc,dc=edu" Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 DEL dn="uid=user2,ou=people,dc=ucsc,dc=edu" Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 DEL dn="uid=user3,ou=people,dc=ucsc,dc=edu" Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 DEL dn="uid=user4,ou=people,dc=ucsc,dc=edu" Nov 17 21:11:55 localhost slapd[1912]: bdb(dc=ucsc,dc=edu): previous transaction deadlock return not resolved Nov 17 21:11:55 localhost slapd[1912]: =>    bdb_idl_delete_key: cursor failed: Invalid argument (22) Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 RESULT tag=107 err=80 text=entry index delete failed Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 DEL dn="uid=user5,ou=people,dc=ucsc,dc=edu" Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 RESULT tag=107 err=0 text=

Strange. The log shows an error occurring while deleting an index. The error message indicates that there was already a deadlock before, but there's no message from the original deadlock, and the indexing code logs *every* error that occurs. Seems more likely a BDB bug.

Also your client is broken, it looks like it completely ignored the failure result from the ldapdelete operation, it just went right on to issue another request.

...

ldapdelete was using the -c option so it just continued I've actually was able to replicate the error on a small local installation using the default openldap install. When I changed it to BDB 4.8 I've yet to see the error. So I'm going to run this a few more times and see if it does indeed fix things.

Fingers crossed

Sounds promising. Looking forward to your conclusion.

Of course, with back-mdb, none of this type of nonsense can ever happen...

--  -- Howard Chu  CTO, Symas Corp.           http://www.symas.com  Director, Highland Sun     http://highlandsun.com/hyc/  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Things look pretty good since going to bdb 4.8. However for future reference, what is the best way to force a replica to simply discard what it has and reload from the provider ldaps. So far all I can do is remove the database and restart. However this means any record it has yet to see is not available until the replica get to that record. I would rather re-sync in such a way that it looks at each records and re-updates or deletes if it cant find the original record on the provider server.

Starting slapd with the -c option isn't working or I'm using the wrong combination.

Thanks Jeffrey