It is caused by the cookie not containing CSN and a race between the syncCookie check in do_syncrep2 and syncrepl_message_to_op.

This race is probably fine with plain syncrepl which is idempotent, but deltasync changes get their own dn in each accesslog instance and some can be applied twice unless we know how to find out we've already seen them - they need to mention the CSN.

The CSN itself gets lost on at least one occasion - when there's a checkpoint triggered. Not 100 % sure why the cookie gets eaten because of it, the op pointer is different between the syncprov_op_response that calls syncprov_checkpoint and the one that decides CSN hasn't changed.

--=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP