On Thu, Jul 9, 2026 at 2:47 AM Ondřej Kuzník ondra@mistotebe.net wrote:
On Wed, Jul 08, 2026 at 11:33:05AM -0700, Ben Poliakoff wrote:
Hi Ondřej,
Which parts of the config would be good to see (sending over the contents of all the ldif files in slapd.d seems like overkill to send to the
list)?
Hi Ben, a list of overlays (the dns of the database's cn=config subtree) plus the sanitised contents of syncprov and syncrepl config should be enough.
The active overlays on the db in question are: dynlist, syncprov, and unique
Here are the sanitized syncrepl configs, please let me know if there are other bits of config I can provide:
dn: olcDatabase={2}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/symas/openldap-data olcSuffix: dc=foo,dc=bar olcAddContentAcl: FALSE olcLastMod: TRUE olcLastBind: FALSE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcRootDN: cn=admin,dc=foo,dc=bar olcSecurity: simple_bind=1 olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=011 provider=ldap://slapd-a.ldap.foo.bar/ bin dmethod=sasl saslmech=gssapi searchbase="dc=foo,dc=bar" type=refreshAnd Persist retry="5 5 300 5" timeout=1 starttls=critical tls_reqcert=dem and olcSyncrepl: {1}rid=012 provider=ldap://slapd-b.ldap.foo.bar/ bin dmethod=sasl saslmech=gssapi searchbase="dc=foo,dc=bar" type=refreshAnd Persist retry="5 5 300 5" timeout=1 starttls=critical tls_reqcert=dem and olcSyncrepl: {2}rid=013 provider=ldap://slapd-c.ldap.foo.bar/ bin dmethod=sasl saslmech=gssapi searchbase="dc=foo,dc=bar" type=refreshAnd Persist retry="5 5 300 5" timeout=1 starttls=critical tls_reqcert=dem and olcMultiProvider: TRUE
Replication appears to have been stable for the past several days, but I
do
continue to see repeated instances of logs (on the consumer) like this, even when replication seems to be working (verified both by watching contextCSN values on producer and consumer, as well as by making changes
to
entries on the primary provider and seeing those changes replicated in
the
consumer):
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).
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.
Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d06e5be 0x7f6d411fc6c0 conn=-1 op=0 syncprov_matchops: recording uuid for dn=uid=example-user,ou=People,dc=foo,dc=bar on opc=0x7f6d2800c550 Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d06f638 0x7f6d411fc6c0 conn=1869 op=4 syncprov_matchops: skipping original sid
001
Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d082b1f 0x7f6d411fc6c0 syncrepl_null_callback : error code 0x7a Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08671e 0x7f6d411fc6c0 syncrepl_entry: rid=011 be_modify uid=example-user,ou=People,dc=foo,dc=bar (122) Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d0896d0 0x7f6d411fc6c0 syncrepl_entry: rid=011 be_search (0) Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08a8b7 0x7f6d411fc6c0 syncrepl_entry: rid=011 uid=example-user,ou=People,dc=foo,dc=bar Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08c461 0x7f6d411fc6c0 conn=-1 op=0 syncprov_matchops: recording uuid for dn=uid=example-user,ou=People,dc=foo,dc=bar on opc=0x7f6d2800c550
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.
Ben