[389-users] incorrect DNs sometimes returned on searches: 1.2.6 and

Noriko Hosoi nhosoi at redhat.com
Thu Oct 14 22:10:28 UTC 2010


Thank you for your response.  Just to make sure your db is not broken, 
could you run these command lines and look for any corrupted DIT link 
when the DN corruption is observed?  The outputs should be huge.  So, I 
recommend you to redirect them to a file.  I think we are interested in 
just around "ou=People,dc=acs,dc=albany,dc=edu" and 
"ou=Group,dc=acs,dc=albany,dc=edu".  Since restarting the server fixes 
the problem, (I'm hoping) you don't see any corruption in this level.

$ dbscan -f /var/lib/dirsrv/slapd-YOURID/db/YOURBACKEND/id2entry.db4 | 
egrep "dn:|entryid:|parentid:"
     rdn: dc=acs,dc=albany,dc=edu
     entryid: 1
     rdn: ou=People
     parentid: 1
     entryid: 2

$ dbscan -f /var/lib/dirsrv/slapd-YOURID/db/YOURBACKEND/entryrdn.db4 -k 
   ID: #; RDN: "ou=People,dc=acs,dc=albany,dc=edu"; NRDN: 

$ dbscan -f /var/lib/dirsrv/slapd-YOURID/db/YOURBACKEND/entryrdn.db4 -k 
   ID: #; RDN: "ou=Group,dc=acs,dc=albany,dc=edu"; NRDN: 


Eric Torgersen wrote:
> Noriko,
>   Please see my comments below.
> On Thu, 14 Oct 2010, Noriko Hosoi wrote:
>>    Eric,
>> Thanks for your input.  It contains lots of useful information.  Can I
>> ask some more details about this section?  The corrupted DN problem is
>> observed only on a replica after a consumer initialization is done?  Or
>> it is observed on the master as well?
> It is mainly observed on the master.  I think I only observed it on the
> replica because I happened to be doing an initialization at a time when
> the master had some of the corrupted DNs in memory.
> On the master, the corrupted DNs can be cleared by a restart - they seem
> to be in memory only.  To fix the replica, I had to reinitialize again
> after restarting the master (because the entries with corrupt DNs were
> written to disk.)  I think the source of the error on the replica was just
> that it was passed bad information from the master.
>> When the incorrect DNs are
>> detected in the consumer initialization, it is rejected due to the
>> invalid DN or just passed through?
> Many were just passed though because they were actually valid, but
> incorrect DNs, in the case where the ou=Group part was dropped from the
> DN:
> dn: cn=mongrp,dc=acs,dc=albany,dc=edu
> A few were rejected because the DN was invalid, like in the case of
> wwwcarey,=albany,,dc=acs,dc=albany,dc=edu
>> Were the events logged in the error
>> log?
> For the rejected DNs, yes:
> [14/Oct/2010:10:35:35 -0400] NSMMReplicationPlugin -
> multimaster_be_state_change
> : replica dc=acs,dc=albany,dc=edu is going offline; disabling replication
> [14/Oct/2010:10:35:35 -0400] - WARNING: Import is running with
> nsslapd-db-privat
> e-import-mem on; No other process is allowed to access the database
> [14/Oct/2010:10:35:56 -0400] - import userRoot: Processed 50368 entries --
> avera
> ge rate 2398.5/sec, recent rate 2398.4/sec, hit ratio 0%
> [14/Oct/2010:10:36:00 -0400] - import userRoot: WARNING: Skipping entry
> "cn=wwwc
> hsr,ou=Group,ou=Group,dc=acs,dc=albany,dc=edu" which has no parent, ending
> at line 0 of file "(bulk import)"
> [14/Oct/2010:10:36:01 -0400] - import userRoot: WARNING: bad entry: ID
> 57588
> ...
> [14/Oct/2010:10:36:08 -0400] - import userRoot: WARNING: Skipping entry
> "cn=wwwtmu,ou=Group,=albany,dc=edu,dc=acs,dc=albany,dc=edu" which has no
> parent, ending at line 0 of file "(bulk import)"
> [14/Oct/2010:10:36:09 -0400] - import userRoot: WARNING: bad entry: ID
> 72233
> ...
> [14/Oct/2010:10:36:39 -0400] - import userRoot: Processed 107643 entries
> -- aver
> age rate 1708.6/sec, recent rate 1363.7/sec, hit ratio 95%
> [14/Oct/2010:10:36:47 -0400] - import userRoot: WARNING: Skipping entry
> "cn=wwwc
> arey,=albany,,dc=acs,dc=albany,dc=edu" which has no parent, ending at line
> 0 of
> file "(bulk import)"
> [14/Oct/2010:10:36:48 -0400] - import userRoot: WARNING: bad entry: ID
> 116490
>> Did you have a chance to search the entry having the corrupted DN
>> (corrupted and original one) on the master then?
> Yes.  The same DNs showed up corrupted on the master, until I restarted
> it.  Then they appeared fine.
> So far, the corrupted DNs seem to be happening less frequently with
>, as compared to 1.2.6.  We have been on since yesterday
> evening, and only had this happen once so far with some of the group
> entries.  On 1.2.6, this was usually happening multiple times per day, and
> affecting user entries.
> Thanks,
> Eric
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

More information about the 389-users mailing list