On Mon, Jul 13, 2026 at 2:34 AM Ondřej Kuzník ondra@mistotebe.net wrote:
Could you provide a little more context from the log? In particular, is the entry being modified locally at the same time? When syncrepl tries to update an entry, it now attaches an assert control ensuring the entry still carries the entryCSN it did as it was trying to figure out what changes were needed. If that failed, it's because **something** updated the entry before syncrepl's change managed to land there and the assert control didn't match anymore.
We do, as a practice, force almost all write operations through a single "primary" slapd instance (slapd-a). So, in general, only syncrepl should
be
making any changes/updates to entries on the two non-primary slapd instances (slapd-b and slapd-c).
Sure, but a longer excerpt of the log for rid=011 might show what else happened during the session as far as the consumer was concerned.
Here's an excerpt from this morning, from one of the consumers, when this issue came up. As near as I can tell, the changes for "user-a" and "user-b" were replicated properly, but in "user-c's" case replication stopped working, and the consumer fell into a loop, which continued until I intervened (by deleting the entry for user-c on the provider, recreating it via ldapadd, and then restarting slapd on both of the consumers):
Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.11cb285b 0x7fe93dbfe6c0 do_syncrep2: rid=011 cookie=rid=011,sid=001,csn=20260713112535.267821Z#000000#001#000000 Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.11cc71cf 0x7fe93dbfe6c0 syncrepl_message_to_entry: rid=011 DN: uid=user-a,ou=People,dc=foo,dc=bar, UUID: 1c96ac22-62f9-1027-8440-e9a9b4c99043 Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.11cff8c3 0x7fe93dbfe6c0 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260713112535.267821Z#000000#001#000000 tid 0x7fe93dbfe6c0 Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.11d1566a 0x7fe93dbfe6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.11d1d463 0x7fe93dbfe6c0 syncrepl_entry: rid=011 uid=user-a,ou=People,dc=foo,dc=bar Jul 13 04:25:35 slapd-c slapd[363788]: 6a54cb2f.150bdf03 0x7fe93dbfe6c0 syncrepl_entry: rid=011 be_modify uid=user-a,ou=People,dc=foo,dc=bar (0) Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.17e1472f 0x7fe8f13fc6c0 do_syncrep2: rid=011 cookie=rid=011,sid=001,csn=20260713141706.387664Z#000000#001#000000 Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.17e1e882 0x7fe8f13fc6c0 syncrepl_message_to_entry: rid=011 DN: uid=user-b,ou=People,dc=foo,dc=bar, UUID: 3a002ff4-912d-103d-9e5f-4fce8756df8d Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.17e3f06b 0x7fe8f13fc6c0 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260713141706.387664Z#000000#001#000000 tid 0x7fe8f13fc6c0 Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.17e49d6c 0x7fe8f13fc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.17e4b9c6 0x7fe8f13fc6c0 syncrepl_entry: rid=011 uid=user-b,ou=People,dc=foo,dc=bar Jul 13 07:17:06 slapd-c slapd[363788]: 6a54f362.1b702746 0x7fe8f13fc6c0 syncrepl_entry: rid=011 be_modify uid=user-b,ou=People,dc=foo,dc=bar (0) Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.3670134f 0x7fe92ddfd6c0 do_syncrep2: rid=011 cookie=rid=011,sid=001,csn=20260713141741.874176Z#000000#001#000000 Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.3670baf2 0x7fe92ddfd6c0 syncrepl_message_to_entry: rid=011 DN: uid=user-a,ou=People,dc=foo,dc=bar, UUID: 1c96ac22-62f9-1027-8440-e9a9b4c99043 Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.36727fb0 0x7fe92ddfd6c0 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260713141741.874176Z#000000#001#000000 tid 0x7fe92ddfd6c0 Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.36732e80 0x7fe92ddfd6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.36734c82 0x7fe92ddfd6c0 syncrepl_entry: rid=011 uid=user-a,ou=People,dc=foo,dc=bar Jul 13 07:17:41 slapd-c slapd[363788]: 6a54f385.38289301 0x7fe92ddfd6c0 syncrepl_entry: rid=011 be_modify uid=user-a,ou=People,dc=foo,dc=bar (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.19271e69 0x7fe93cbfc6c0 do_syncrep2: rid=011 cookie=rid=011,sid=001,csn=20260713162914.373110Z#000000#001#000000 Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.192880c7 0x7fe93cbfc6c0 syncrepl_message_to_entry: rid=011 DN: uid=user-c,ou=People,dc=foo,dc=bar, UUID: 1b6a45a2-f7c6-1033-8b7c-2b6875adc332 Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.192d38b8 0x7fe93cbfc6c0 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260713162914.373110Z#000000#001#000000 tid 0x7fe93cbfc6c0 Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.192ea929 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.192ef1a2 0x7fe93cbfc6c0 syncrepl_entry: rid=011 uid=user-c,ou=People,dc=foo,dc=bar Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1936d2f0 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_modify uid=user-c,ou=People,dc=foo,dc=bar (122) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1937a1db 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1937e217 0x7fe93cbfc6c0 syncrepl_entry: rid=011 uid=user-c,ou=People,dc=foo,dc=bar Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.193df998 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_modify uid=user-c,ou=People,dc=foo,dc=bar (122) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.193ea7e9 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.193ee30b 0x7fe93cbfc6c0 syncrepl_entry: rid=011 uid=user-c,ou=People,dc=foo,dc=bar Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1944b039 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_modify uid=user-c,ou=People,dc=foo,dc=bar (122) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.19456ca6 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1945b723 0x7fe93cbfc6c0 syncrepl_entry: rid=011 uid=user-c,ou=People,dc=foo,dc=bar Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.194c31ad 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_modify uid=user-c,ou=People,dc=foo,dc=bar (122) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.194cdb08 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_search (0) Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.194d15b1 0x7fe93cbfc6c0 syncrepl_entry: rid=011 uid=user-c,ou=People,dc=foo,dc=bar Jul 13 09:29:14 slapd-c slapd[363788]: 6a55125a.1952a424 0x7fe93cbfc6c0 syncrepl_entry: rid=011 be_modify uid=user-c,ou=People,dc=foo,dc=bar (122)
...etc
And (but there isn't sufficient information in the logs) the retried modification (rereading the entry and checking what to do) probably succeeded. If you temporarily enable accesslog on the database and record both successful and failed operations, we might be able to see what happened in detail.
The syncrepl process seems to get hung up "every so often" (might run
for
several days without issue). Today I found that it had gotten "stuck"
again
(newer change to an entry on slapd-a that wasn't being propagated to
slap-b
and slapd-c). Sometimes in these cases, simply restarting slapd on the non-primary instances gets things moving again. Today, though, that
didn't
work, and I was only able to get replication moving again, by deleting
the
entry (on the primary slapd instance) that was being referenced in the logs, and then recreating it (also on the primary slapd instance).
I'll try enabling accesslog on our test cluster (to make sure I know how
to
do that cleanly) and then try enabling it on our test cluster.
Great, that will also help. Thanks.
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP