[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5342) DN and naming attribute mismatch

> after it. ("Last" is obviously imprecise. But the point is you would have had 
> to have created some new entries after the upgrade whose DNs would cause 
> their records to fall on the same DB page as this record, meaning they're 
> close in the sort order and such.)

As for "close pagewise," there's a lot of churn here since it's the 
beginning of the semester. It's not uncommon to see the same DN DEL/ADD 
within ~30-60 minutes.

> And for most err=80 situations, there ought to be BerkeleyDB error messages 
> in the log as well.

Agreed. On that end, I pulled out two weeks of logs overnight, and grep 
for "bdb(" found precisely zero hits.

While I had the logs out, I looked back, and it turns out the first time I 
ever saw a problem with 2.3.40 actually WASN'T err=80:

Jan 24 19:03:31 op=4 DEL dn="cn=,cn..."
Jan 24 19:03:31 conn=3252 op=4 RESULT tag=107 err=32 text=

This was added under 2.3.37:

Jan 22 18:33:28 op=4 ADD dn="cn=,cn=..."

Now of course you can blame stuff between Jan 22-24 as moving that entry. 
But I've got nightly slapcat's showing:

dn: cn=,cn=Clients,cn=ResNet Service Config,ou=Host Config,o=Rutg
entryCSN: 20080122233328Z#000004#00#000000

As a matter of fact, I can even run that right this second.

# date;slapcat -b "o=Rutgers CCF,c=US" | /usr/sfw/bin/ggrep -A12 cn= | egrep '^cn|^entryCSN'
Wed Jan 30 09:29:03 EST 2008
entryCSN: 20080122233328Z#000004#00#000000

So notfound is.....dubious. (And no, I'm not manually tweaking it, and I 
don't even know how to spell managedSAit. ;) That's the first time I saw 
2.3.40 go weird.