[389-users] incorrect DNs sometimes returned on searches: 1.2.6 and 22.214.171.124
eric at albany.edu
Thu Oct 14 21:42:21 UTC 2010
Please see my comments below.
On Thu, 14 Oct 2010, Noriko Hosoi wrote:
> 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
A few were rejected because the DN was invalid, like in the case of
> Were the events logged in the error
For the rejected DNs, yes:
[14/Oct/2010:10:35:35 -0400] NSMMReplicationPlugin -
: replica dc=acs,dc=albany,dc=edu is going offline; disabling replication
[14/Oct/2010:10:35:35 -0400] - WARNING: Import is running with
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 --
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
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
[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
[14/Oct/2010:10:36:39 -0400] - import userRoot: Processed 107643 entries
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
arey,=albany,,dc=acs,dc=albany,dc=edu" which has no parent, ending at line
file "(bulk import)"
[14/Oct/2010:10:36:48 -0400] - import userRoot: WARNING: bad entry: ID
>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
126.96.36.199, as compared to 1.2.6. We have been on 188.8.131.52 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.
More information about the 389-users