https://bugs.openldap.org/show_bug.cgi?id=10541
Issue ID: 10541 Summary: syncrepl regression with older format of entryCSN Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: benp@reed.edu Target Milestone: ---
We recently upgraded from openldap 2.6.10 to 2.6.13 (using debian packages from symas.com). Subsequent to the upgrade we noticed that syncrepl was sometimes failing to replicate changes to entries.
It appears that the behavior is triggered when modifying an entry with an older style entryCSN (eg "entryCSN: 20210115230536Z#000001#00#000000" vs the current style "entryCSN: 20260715174316.844052Z#000000#001#000000"). The updated entry on the provider slapd gets a new entryCSN that uses the new format, but the consumer slapds don't process the changes made to the entry, and log a failed assertion (122) error like this:
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)
Deleting the problematic entry on the provider and then recreating it tends to resolve the issue for us, presumably because the new entry has the normal non-obsolete contextCSN attribute.
Our current production DB has ~22k entries, ~4k of which have older style contextCSNs, so we'd love to avoid having to delete and recreate those ~4k entries if we don't have to.
We have entryCSNs in at least 3 different formats:
entryCSN: 2003081423:11:31Z#0x000d#0#0000 entryCSN: 20230410142047Z#000000#00#000000 entryCSN: 20260313112653.221151Z#000000#001#000000
Our current configuration does not use accesslog, so replication is simple syncrepl (vs delta-syncrepl).
It was suggested on the openldap-technical list that we consider filing an ITS about this issue. Please let me know what additional supporting information would be helpful. I'm not totally certain how to distill are slapd.d style config to something concise enough for the bug tracker.
https://bugs.openldap.org/show_bug.cgi?id=10541
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED
--- Comment #1 from Howard Chu hyc@openldap.org --- After running test050, I slapcat'd the DB and then manually changed Bjorn Jensen's entryCSN to 20210115230536Z#000001#00#000000, added that to the contextCSN, then loaded this DB on all of the servers.
Then did an ldapmodify on Bjorn Jensen to see what happened to its replication. The log shows the LDAP assert failed.
6a5e4a3e.0b0b6fe1 0x77ea17fff6c0 mdb_modify: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com 6a5e4a3e.0b0b7f29 0x77ea17fff6c0 mdb_dn2entry("cn=bjorn jensen,ou=information technology division,ou=people,dc=example,dc=com") 6a5e4a3e.0b0b8e2a 0x77ea17fff6c0 => mdb_dn2id("cn=bjorn jensen,ou=information technology division,ou=people,dc=example,dc=com") 6a5e4a3e.0b0ba0fd 0x77ea17fff6c0 <= mdb_dn2id: got id=0x9 6a5e4a3e.0b0bb1e7 0x77ea17fff6c0 => mdb_entry_decode: 6a5e4a3e.0b0bc9a3 0x77ea17fff6c0 <= mdb_entry_decode 6a5e4a3e.0b0bda48 0x77ea17fff6c0 => test_filter 6a5e4a3e.0b0be71a 0x77ea17fff6c0 EQUALITY 6a5e4a3e.0b0bf28f 0x77ea17fff6c0 => access_allowed: search access to "cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com" "entryCSN" requested 6a5e4a3e.0b0c0191 0x77ea17fff6c0 <= root access granted 6a5e4a3e.0b0c1092 0x77ea17fff6c0 => access_allowed: search access granted by manage(=mwrscxd) 6a5e4a3e.0b0c1f93 0x77ea17fff6c0 <= test_filter 5 6a5e4a3e.0b0c2a7d 0x77ea17fff6c0 send_ldap_result: rid=011 p=0 6a5e4a3e.0b0c39c4 0x77ea17fff6c0 send_ldap_result: err=122 matched="" text="" 6a5e4a3e.0b0c4a23 0x77ea17fff6c0 syncrepl_null_callback : error code 0x7a 6a5e4a3e.0b0c5e53 0x77ea17fff6c0 slap_graduate_commit_csn: removing 0x77ea0010c2f0 20260720161806.174213Z#000000#001#000000 6a5e4a3e.0b0c730f 0x77ea17fff6c0 syncrepl_entry: rid=011 be_modify cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com (122)
Probably the assertion isn't using the normalized value.
https://bugs.openldap.org/show_bug.cgi?id=10541
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10358
https://bugs.openldap.org/show_bug.cgi?id=10541
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|CONFIRMED |RESOLVED Target Milestone|--- |2.6.14 Assignee|bugs@openldap.org |hyc@openldap.org Resolution|--- |TEST
--- Comment #2 from Howard Chu hyc@openldap.org --- Fixed in master 595e7ea6f36d5352af5a60eccef64c5cb3357fb2
https://bugs.openldap.org/show_bug.cgi?id=10541
--- Comment #3 from Quanah Gibson-Mount quanah@openldap.org --- head:
• 595e7ea6 by Howard Chu at 2026-07-20T17:42:05+01:00 ITS#10541 syncrepl: assert on entryCSN must use normalized value
RE27:
• dff88819 by Howard Chu at 2026-07-21T13:56:05+00:00 ITS#10541 syncrepl: assert on entryCSN must use normalized value
RE26:
• b09d4347 by Howard Chu at 2026-07-21T13:56:15+00:00 ITS#10541 syncrepl: assert on entryCSN must use normalized value
https://bugs.openldap.org/show_bug.cgi?id=10541
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org