Howard Chu wrote:
michael@stroeder.com wrote:
BTW: This is git master (formerly known as HEAD).
See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz
I see, and I was also able to reproduce it here. The difference is that on server2, 2 of the entries have objectClass: glue instead of their correct objectclasses. From the diffs, this affected cn=schema,cn=config and olcDatabase={0}config,cn=config. Looking at the logs, this happened because during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't match the UUIDs sent from some other master, so syncrepl attempted to delete them.
Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config are always created automatically by each slapd, so naturally their UUIDs differ on each server. But, also generally, after the first refresh each consumer would modify their local entries and overwrite the UUIDs with the ones received from their provider. Not sure why this didn't happen this time around.
Ah this is a simple timing issue in the test startup; the incoming entry was ignored because its entryCSN was older than the local one.
(back-config explicitly prevents any attempts to delete both of these entries. When syncrepl fails to delete an entry, it does a modify to change the objectclass to glue, which explains how they got to their final state when the test aborted.)
I guess we can try to patch the startup sequencing of the script; this problem can only occur in cn=config, because of the special nature of the cn=schema and olcDatabase={0}config entries.