replication of ldap stops working after server restart

Jan Kowalsky tuxus at notraces.net
Thu Feb 13 10:17:19 CET 2014


Hi all,

while trying setting up an master-slave replication with one supplier and one 
consumer I run in the following problem.

After initializing replication all works fine. But if I restart the dirsrv on 
the supplier once replication stops and can't initialized again.

I'm running kolab 3.1 on debian wheezy with 1.2.11.15-1 

I find in the logs:

12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - Found replication 
agreement named "cn=test 
replica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping 
tree,cn=config".
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - The replication 
agreement named "cn=test 
replica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping 
tree,cn=config" could not be correctly parsed. No replication will occur 
with this replica.
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - 
agmtlist_config_init: found 0 replication agreements in DIT
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - changelog program - 
_cl5GetDBFile: found DB object 1d9bbf0 for database 
/var/lib/dirsrv/slapd-ldapmaster
1/changelogdb/bbd31b03-93cd11e3-8fe4ea88-51d1475b_52fb486f000000070000.db4
[12/Feb/2014:12:04:51 +0100] - _csngen_adjust_local_time: gen state 
before 52fb486f0001:1392199791:0:0
[12/Feb/2014:12:04:51 +0100] - _csngen_adjust_local_time: gen state 
after 52fb55530000:1392203091:0:0
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - 
ruv_add_csn_inprogress: successfully inserted csn 52fb5553000000070000 
into pending list
[12/Feb/2014:12:04:52 +0100] NSMMReplicationPlugin - Purged state 
information from entry dc=datenkollektiv,dc=net up to CSN 
52f2180c000000070000

The replication agreement should be fine - at least Rich from the 389-users 
Mailinglist confirmed. I haven't got experience with replication yet.

I putted my replication ldif statements all here:

All Definitions for replication provided during setup:
   https://gist.github.com/jankowa/4bc116c91c0d2a95e622

And some detailed logs:

Master log after server restart (replication isn't working anymore)
   https://gist.github.com/jankowa/ddce7791c2f681c54170

Master log before server restart (with working replication)
   https://gist.github.com/jankowa/33dfc8404d5b1f0bf3dc

Slave log before server restart
   https://gist.github.com/jankowa/e21899821aa02a5d8211



I tried again to reproduce in a fresh environment: still the same error, 
completely reproducable. Same happend in tests with multimaster with two 
masters.

Alwo I tried to update 389-ds to a newer version ( 1.3.0.3-1 in debian 
unstable) but the error remains.

Anybody who has the same problem? Is it an debian specific bug?

Best  Regards
Jan



More information about the users mailing list