Ben Poliakoff wrote:
On Thu, Jul 16, 2026 at 6:39 AM Howard Chu <hyc@symas.com mailto: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#000000 These 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 issueI 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?
Sounds like a bug in the consumer, it should be perfectly able to process the older CSN formats.
If you could supply a small sample DB and config that demonstrates this problem, submit it to the ITS.