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