apm@mutex.dk wrote:

Full_Name: Peter Mogensen Version: 2.4.19 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.166.36.16)

Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a mirrormode setup:

• Load the database with slapadd on server-1, start server-1 The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 Running on Debian Etch. I have no reason to suspect that it is not loaded correctly into server1

• Start server-2 and monitor the progress of replication with slapcat, for

example:

# for ((I=1;I<=20;I++)); do slapcat > out-$I; done

• Look at the output:

# for ((I=1;I<=20;I++)); do wc -l out-$I; done

I would expect the generated files to be strictly increasing in size. However, some times there's a file which is smaller than the previous. In it I see LDIF entries like this:

dn: objectClass: top objectClass: NamedObject objectClass: simpleSecurityObject uid: rieke userPassword:: e1NBU0x..... structuralObjectClass: NamedObject entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 creatorsName: dc=admin,dc=example,dc=com createTimestamp: 20070823185333Z entryCSN: 20070823185333.000000Z#000002#000#000000 modifiersName: dc=admin,dc=example,dc=com modifyTimestamp: 20070823185333Z

... with an empty DN line.

You appear to be using back-hdb. I note that in bdb_tool_entry_get() there is code specific to back-hdb that tries to lookup the parent of the current entry and, if found, "fixes" its DN.

My guess is that if this can fail, e.g. because entries are being sync'ed out of order, the DN does not get fixed. If this is the case (I couldn't inspect code deep enough to make sure), I'd expect that the DN get fixed anyway, though, because missing entries should exist as "glue" objects.

I apologize for the rather incomplete analysis, I can't dig further right now. I hope this provides some hint to others, unless completely wrong.

p.