[Date Prev][Date Next]
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=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
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
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.