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

[hyc@symas.com]

Aaron Richton wrote:
>> 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=172.23.132.58,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=172.23.132.58,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=172.23.132.58,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=172.23.132.58 | egrep '^cn|^entryCSN'
> Wed Jan 30 09:29:03 EST 2008
> cn: 172.23.132.58
> 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.

Well, one of the big patches in 2.3.40 (relative to 2.3.39) was a fix for some 
caching bugs which showed up if an entry was being deleted and added in rapid 
succession, and being searched for. In that case, it was possible for the old 
dn2id value to be read back into the cache from disk before it got deleted off 
the disk. So it's conceivable that this patch caused your err=32 problem 
somehow. But nothing explains the errant bit getting set in the DN.

Have you got any servers running 2.3.39, or all 2.3.37?
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/