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:
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDbDirectory: /var/symas/openldap-data
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
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
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
> 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