[Date Prev][Date Next]
Re: (ITS#6365) Bad slapcat output when slapd running
> Full_Name: Peter Mogensen
> Version: 2.4.19
> OS: Debian Lenny
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (184.108.40.206)
> 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
> # 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:
> 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"
I apologize for the rather incomplete analysis, I can't dig further
right now. I hope this provides some hint to others, unless completely