On Thu, Nov 17, 2011 at 11:47 PM, Howard Chu <[email protected]> wrote: > Jeffrey Crawford wrote: >> >> On Thu, Nov 17, 2011 at 9:21 PM, Howard Chu<[email protected]> wrote: >>> >>> Jeffrey Crawford wrote: >>>> >>>> On Thu, Nov 17, 2011 at 5:50 PM, Howard Chu<[email protected]> 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
