On Tue, Aug 05, 2025 at 12:50:44PM +0000, Windl, Ulrich wrote:
Hi!
I have a support case from SUSE's version of slapd open, and I wonder about one specific statement from support:
A core dump is triggered by
syncprov.c:2360:
assert( !BER_BVISEMPTY( &oldestcsn ) && !BER_BVISEMPTY( &newestcsn ) && ber_bvcmp( &oldestcsn, &newestcsn ) < 0 );
Support explained: "Any of these indicates the changelog (accesslog) is in a completely inconsistent or corrupted state."
Hi Ulrich, based on what have they concluded this? There is very little to go on in what you've provided here.
Again as with all reports of crashes and desyncs, please file an ITS at bugs.openldap.org or encourage them to do so: - if you can reproduce the issue with sample data, please provide a way to do so, this is universally the best way to ensure we can diagnose and address a bug - provide as much information as possible, at a minimum relevant parts of configuration, "sync"-level logs, ... from all servers involved - provide the values of contextCSN and minCSN on the main and accesslog DBs on all the servers involved (in addition to the logs from that event)
Without this you're just hoping someone else encounters this issue and does the right thing of giving us the information we need to isolate it.
The support recommends to reset the CSNs by disabling any replication (which doesn't remove those IMHO) and "either using syncrepl or delta-syncrepl, but not mixing both.":
I don't see a problem if one dependent server gets the changed through "classic methods" (e.g. Refresh), and another server gets updates through delte-syncrepl. Am I wrong?
Stating "either using syncrepl or delta-syncrepl, but not mixing both." sounds concerning. You haven't provided any sort of configuration snippets or even basic description of your set up to say if we should be concerned about this.
Are these servers also providers? All providers need to have *identical* configuration and *full* read access to other provider's DB (both main DB and accesslog if used).
Finally support concludes: "Please note that these types of replication integrity issues do not affect 389 Directory Server, which uses a more robust mechanism for change tracking and includes a proper Lamport clock implementation."
AFAIK 389DS replication is push based, so the design and behaviours are quite different. Also assuming we're looking at the above, their comment seems somewhat random in context.
Well, I actually tried 389DS, but the conversion tool was highly incomplete, the schemata and ACL mechanism were completely different, and there was not a single current book for it available, so I resigned.
Regards,