On Thu, Jul 16, 2026 at 6:39 AM Howard Chu hyc@symas.com wrote:
Ben Poliakoff wrote:
Just noticed another thing when this issue comes up.... the entryCSN for
an entry that's not replicating from the primary server to the two consumers has a
slightly different format:
Primary/provider: entryCSN: 20260715174316.844052Z#000000#001#000000 Non-primary/consumer: entryCSN: 20210115230536Z#000001#00#000000 entryCSN: 20210115230536Z#000001#00#000000These are in an obsolete format, last used in OpenLDAP 2.3. No OpenLDAP software has produced them in the last 20 years.
That's interesting. In our environment we have a mix of these two formats (I assume the shorter format being the obsolete one). About a fifth of our ~22k entries (4291) have the shorter format of entryCSN.
I see now that I can reliably trigger this issue: by modifying an entry with the shorter (obsolete?) form of entryCSN. When I do that the entryCSN is updated on the primary/provider slapd instance (the *updated* entryCSN is in the longer format), and the syncrepl replication process fails to sync those changes on the non-primary/consumer slapd instances. Doing an ldapdelete of the entry in question (on the primary/provider) followed by an ldapadd of the entry on the primary/provider results in the newly created entry being replicated to the two consumer slapd instances.
So it appears that perhaps I need to "fix" all of the entries with the older format of entryCSN. My quick "fix" that I've been doing when this issue comes up has been to:
1. create an ldif of the entry in question 2. delete the entry in question on the primary/provider slapd instance 3. re-create the entry on the primary/provider, using the ldif from step one 4. at this point subsequent changes to the entry are replicated promptly and without issue
I don't love the idea of having to do this ~4k times, but can certainly do that if that's the best way forward. Is there any better/more efficient way to fix these entries with entryCSNs that are in the older format?
Ben