openldap-bugs October 2026

openldap-bugs@openldap.org

1 participants
73 discussions

[Issue 10599] New: Compile error on Suse and older GCCs
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10599 Issue ID: 10599 Summary: Compile error on Suse and older GCCs Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dstoychev(a)symas.com Target Milestone: --- Created attachment 1213 --> https://bugs.openldap.org/attachment.cgi?id=1213&action=edit Diff of an example solution When building OpenLDAP on openSUSE 15.6 (which uses gcc 7) I get these errors: ``` tls_o.c: In function ‘tlso_ctx_init’: tls_o.c:547:7: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT( info ); ^~~~ tls_o.c:548:7: error: expected expression before ‘X509_STORE’ X509_STORE *store = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ tls_o.c:549:34: error: ‘store’ undeclared (first use in this function) if ( !X509_STORE_add_cert( store, cert ) ) { ^~~~~ tls_o.c:549:34: note: each undeclared identifier is reported only once for each function it appears in tls_o.c:757:6: error: a label can only be part of a statement and a declaration is not a statement X509 *cert = OSSL_STORE_INFO_get0_CERT(info); ^~~~ tls_o.c:758:6: error: expected expression before ‘int’ int is_ca = X509_check_ca( cert ); ^~~ tls_o.c:759:12: error: ‘is_ca’ undeclared (first use in this function); did you mean ‘ns_c_2’? if ( !is_ca && !SSL_CTX_use_certificate( ctx, cert )) { ^~~~~ ns_c_2 tls_o.c:777:6: error: a label can only be part of a statement and a declaration is not a statement X509_STORE *x509_s = SSL_CTX_get_cert_store( ctx ); ^~~~~~~~~~ ``` It does not happen on newer GCCs. This appears to be because on older GCC it is not allowed to have variable assignment right after a label and in tls_o.c there are `case` labels followed by a variable assignment (X509 *cert = OSSL_STO...) . One way to fix this is by putting the body of the case inside curly braces {}. Attaching an example diff that works to fix the issue for me. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10596] New: back-ldap: tainting of a cached connection doesn't remove it from cache
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10596 Issue ID: 10596 Summary: back-ldap: tainting of a cached connection doesn't remove it from cache Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The patch for ITS#10550 was incomplete and missed the removal when only tainting. This eventually leaves a freed connection in the tree. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10455] New: Allow handling of empty group in memberof_saveMember_cb()
by openldap-its＠openldap.org 09 Oct '26

09 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10455 Issue ID: 10455 Summary: Allow handling of empty group in memberof_saveMember_cb() Product: OpenLDAP Version: 2.6.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: roger.j.meier(a)gmx.ch Target Milestone: --- Created attachment 1117 --> https://bugs.openldap.org/attachment.cgi?id=1117&action=edit Protect e_attrs with a NULL pointer test instead of an assert() to allow empty groups In slapd/overlays/memberof.c, the callback memberof_saveMember_cb() uses two assert statements for the sr_entry and its e_attrs pointer in sequence. This makes the service abort on an empty group. If the use of rs->sr_entry->e_attrs is just protected by a test of the e_attrs pointer, the code does not abort and allows empty groups. Please consider to add this patch to the official source. It was now several month in production and did not lead to unexpected results. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 5500] comments in cn=config entries
by openldap-its＠openldap.org 08 Oct '26

08 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=5500 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10619 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10618] New: [PATCH] improved docs for LDAP proxied authorization
by openldap-its＠openldap.org 07 Oct '26

07 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10618 Issue ID: 10618 Summary: [PATCH] improved docs for LDAP proxied authorization Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: equinox-openldap(a)diac24.net Target Milestone: --- Spent more time getting PAC to work than should've been necessary, so here's 2 small documentation patches (against git master, ba00b19c2ae4) to remove stumbling blocks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10401] New: liblber: undefined shift of -1 in ber_decode_int()
by openldap-its＠openldap.org 07 Oct '26

07 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10401 Issue ID: 10401 Summary: liblber: undefined shift of -1 in ber_decode_int() Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Report from curl project. Full info here https://gist.github.com/bagder/44a0711fa1989951f2a2395fe992530e Relevant stack trace: [Environment] UBSAN_OPTIONS=exitcode=77:print_stacktrace=1:silence_unsigned_overflow=1 +----------------------------------------Release Build Stacktrace----------------------------------------+ Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap -rss_limit_mb=2560 -timeout=60 -runs=100 /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c Time ran: 0.14911556243896484 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1947994398 INFO: Loaded 1 modules (211579 inline 8-bit counters): 211579 [0x559e5bb87a40, 0x559e5bbbb4bb), INFO: Loaded 1 PC tables (211579 PCs): 211579 [0x559e5bbbb4c0,0x559e5bef5c70), /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap: Running 1 inputs 100 time(s) each. Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c decode.c:316:21: runtime error: left shift of negative value -1 #0 0x559e5b730e08 in ber_decode_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:316:21 #1 0x559e5b730c5d in ber_get_int curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:293:9 #2 0x559e5b6e60f3 in try_read1msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:592:7 #3 0x559e5b6e60f3 in wait4msg curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:393:12 #4 0x559e5b6e60f3 in ldap_result curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:120:7 #5 0x559e5af804d6 in oldap_connecting curl/lib/openldap.c:826:10 #6 0x559e5aead984 in protocol_connecting curl/lib/multi.c:1794:14 #7 0x559e5aead984 in multi_runsingle curl/lib/multi.c:2510:16 #8 0x559e5aeacd4f in curl_multi_perform curl/lib/multi.c:2791:18 #9 0x559e5ae7fb38 in fuzz_handle_transfer(fuzz_data*) curl_fuzzer/curl_fuzzer.cc:419:5 #10 0x559e5ae7eff0 in LLVMFuzzerTestOneInput curl_fuzzer/curl_fuzzer.cc:97:3 #11 0x559e5add608d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 #12 0x559e5adc0e02 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6 #13 0x559e5adc6cd0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9 #14 0x559e5adf2802 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #15 0x7c4beb5b7082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16 #16 0x559e5adb9eed in _start SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior decode.c:316:21 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10613] New: On old PowerPC Mac with Mac OS X 10.5.8 (Leopard) test suite fails in test017-syncreplication-refresh
by openldap-its＠openldap.org 06 Oct '26

06 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10613 Issue ID: 10613 Summary: On old PowerPC Mac with Mac OS X 10.5.8 (Leopard) test suite fails in test017-syncreplication-refresh Product: OpenLDAP Version: 2.6.14 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: Peter_Dyballa(a)Web.DE Target Milestone: --- This is the actual report: >>>>> 00:07:04 Failed test017-syncreplication-refresh for mdb after 47 seconds How to debug? -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10614] New: On old PowerPC Mac with macOS High Sierra, Version 10.13.6 test suite fails in test050-syncrepl-multiprovider
by openldap-its＠openldap.org 06 Oct '26

06 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10614 Issue ID: 10614 Summary: On old PowerPC Mac with macOS High Sierra, Version 10.13.6 test suite fails in test050-syncrepl-multiprovider Product: OpenLDAP Version: 2.6.14 Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: Peter_Dyballa(a)Web.DE Target Milestone: --- This is the actual report: >>>>> 00:10:56 Failed test050-syncrepl-multiprovider for mdb after 115 seconds How to debug? -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 2b8cbe0a by Howard Chu at 2026-10-01T17:27:59+01:00 ITS#8884 slapo-rwm: don't strip entryDN in rwm_operational() It only needs to be stripped if it occurs in the main entry. In rs_operational it needs to be mapped, not stripped. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10604] New: Consumer silently loses a contiguous block of entries under sustained write load via standard syncrepl (refreshAndPersist), N-Way Multi-Master
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10604 Issue ID: 10604 Summary: Consumer silently loses a contiguous block of entries under sustained write load via standard syncrepl (refreshAndPersist), N-Way Multi-Master Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dns.spiros(a)gmail.com Target Milestone: --- Summary (Architecture in brief: N-Way Multi-Master with 3 master nodes plus one read-only consumer in a hub-and-spoke arrangement, each node a separate VM with 4GB RAM / 2 vCPU on VMware Workstation - full detail under "Environment" below.) Under a sustained burst of Add operations on a single provider (roughly 500-1000+ operations at a rate of one every 5-50ms), one or more standard syncrepl consumers, in refreshAndPersist mode, silently fail to apply a contiguous block of entries - typically a few dozen, occasionally into the low hundreds. The missing entries are never retried: they are not present in the consumer's database, contextCSN on the consumer nonetheless advances to a value consistent with having processed them, and no error is logged. The condition has been observed to persist indefinitely until the affected slapd instance is restarted, at which point a full resync corrects it. The same underlying symptom (entries reported by a consumer as "<csn> not new enough, ignored" that were, per direct inspection, never actually applied by that consumer) has also been reproduced in a scenario involving an unclean shutdown ( kill -9 ) of two of three masters mid-write in an N-Way Multi-Master mesh, with one provider (captured live in its own log, loglevel: sync ) responding "nothing changed" / an empty-cookie refreshDelete to three simultaneous consumer sessions while its own local entry count was itself well behind the true dataset size. We are not certain of the exact internal root cause. We are reporting this because the minimal reproduction below is clean, small, and - in our testing - reliably triggers the symptom at or above roughly 1000 sequential Add operations on a single provider/single consumer pair, with no crash, no network impairment, and no other variable we have been able to identify as causal (see "Ruled out" below). Environment slapd version: 2.6.10+dfsg-0ubuntu0.24.04.1 (Ubuntu 24.04 LTS package: slapd -VV → @(#) $OpenLDAP: slapd 2.6.10+dfsg-0ubuntu0.24.04.1 (Sep 23 2025 16:26:39) $ ) Note on distribution packaging: this is the Ubuntu-maintained package, not a build from upstream OpenLDAP source. We are aware that issues specific to a distributor's packaging are generally referred back to the distributor, and we have not yet reproduced this against a vanilla build from OpenLDAP Git/release source. We are reporting it here first because the symptom appears to sit in core slapo-syncprov / syncrepl logic rather than anything Ubuntu-specific in the packaging, but we cannot rule out a packaging-specific contribution and would welcome guidance on whether a from-source reproduction is a prerequisite before this can be considered further. Backend: mdb (LMDB) Topology: N-Way Multi-Master, 3 provider/master nodes + 1 olcReadOnly: TRUE consumer-only node, in a hub-and-spoke arrangement (full mesh - refreshAndPersist between every pair of masters - with the read-only node as a spoke carrying three independent syncrepl directives, one toward each master) Hardware: 4 separate virtual machines (one per node), each 4GB RAM / 2 vCPU, on VMware Workstation Replication mode: standard syncrepl , type=refreshAndPersist . delta-syncrepl is deliberately not used. TLS/auth: mutual TLS, bindmethod=sasl saslmech=EXTERNAL , certificate CN mapped via olcAuthzRegexp to a per-node identity DN. Relevant olcSyncRepl directive (one per peer, rid varies): olcSyncRepl: rid=NNN provider=ldaps://<peer>:636 bindmethod=sasl saslmech=EXTERNAL searchbase="<basedn>" type=refreshAndPersist retry="5 10 10 30 60 120 300 +" timeout=5 network-timeout=5 keepalive=10:5:2 tls_cacert=<path> tls_cert=<path> tls_key=<path tls_reqcert=demand attrs="*,+" exattrs="memberOf" slapo-syncprov overlay parameters: olcSpSessionlog: 2000000 olcSpCheckpoint: 1000 10 (tested at both the above and a much tighter 50 1 - see "Ruled out") Other overlays in the stack (order matters, listed innermost first): memberof (index {1}, olcMemberOfRefInt: FALSE , exattrs="memberOf" on all syncrepl directives so it is computed locally and not replicated), refint (index {2}, referential integrity on member / uniqueMember / manager / owner , explicitly not on memberOf ), nestgroup (index {3}, search-time only, no writes), ppolicy (index {4}). syncprov sits outermost (index {0}). Search/size limits: verified unlimited both per-identity ( olcLimits matching the mTLS peer DNs used by syncrepl ) and at the frontend database level ( olcSizeLimit / olcTimeLimit on olcDatabase= {-1}frontend,cn=config ). Ruled out as a factor (see below). Minimal reproduction This is the cleanest form in which we have triggered the symptom: 1. A single provider (one master), a single persistent refreshAndPersist consumer. The other two masters in the mesh are stopped for this reproduction, to remove any multi-provider interaction as a variable. 2. Database freshly initialized/empty on both sides (a clean redeploy, not a preexisting dataset). 3. A namespace never used in any previous run (a fresh, timestamp-based DN prefix each run), to rule out any interaction with residual state or CSN history from prior test iterations. 4. From the provider, over a single reused connection ( ldapadd -x -c ), add N entries of class inetOrgPerson , one every 5ms (results identical at 50ms - see "Ruled out"): dn: uid=<prefix>.<i>,ou=People,<basedn> objectClass: top objectClass: inetOrgPerson uid: <prefix>.<i> cn: Test User <i> sn: Test userPassword: {SSHA}... 5. Wait for replication to settle (well past any configured retry interval), then count entries matching uid=<prefix>.* independently on the provider and on the consumer ( slapcat -a , not ldapsearch , to rule out any client-side search limit). Result across repeated runs: N=500 converges correctly in most runs, but not all (see "Notes on determinism" below). N=1000 and above have, in our testing, shown the symptom in the large majority of runs. When it occurs, the consumer is missing a contiguous range of entries (e.g. entries 474-504 of 2000 in one run; 1584-1604 of 2000 in a different run on a different consumer node; 299-320 of 1000 in a run using the never-before-used-namespace variant above). The size and position of the missing range vary between runs; its contiguity does not. Direct log evidence 1. A consumer receiving, but never applying, an entry - later resolved by a different peer within the same run (this run happened to be an N-Way mesh, so a second delivery path existed; in the single-provider minimal reproduction above, no such second path exists): syncrepl_message_to_entry: rid=101 DN: uid=crash.user.474,ou=people,dc (no corresponding be_add / syncrepl_entry follows for rid=101 at this point - the message is received and converted, but not applied) Several minutes later, in the same log, from a different provider session on the same consumer: syncrepl_message_to_entry: rid=103 DN: uid=crash.user.474,ou=people,dc syncrepl_entry: rid=103 uid=crash.user.474,ou=people,dc=example,dc=com syncrepl_entry: rid=103 be_add uid=crash.user.474,ou=people,dc=example do_syncrep2: rid=101 CSN too old, ignoring 20260921191238.368843Z#0000 do_syncrep2: rid=102 CSN too old, ignoring 20260921191238.368843Z#0000 2. A provider reporting "nothing changed" to three simultaneous consumers, including one whose own dataset was independently confirmed (via direct slapcat on that consumer, at the same moment) to be missing 163 of 500 expected entries: conn=1000 op=1 syncprov_op_search: no change, skipping log replay conn=1000 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1000 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1001 op=1 syncprov_op_search: no change, skipping log replay conn=1001 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1001 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1002 op=1 syncprov_op_search: no change, skipping log replay conn=1002 op=1 syncprov_op_search: nothing changed, finishing up initi conn=1002 op=1 syncprov_sendinfo: refreshDelete cookie= conn=1002 in this excerpt authenticated as the read-only consumer node (certificate CN mapped accordingly); the provider told it nothing had changed, and issued a refreshDelete with an empty cookie value. At the same wall-clock moment, slapcat -a run directly and locally on the provider itself returned 337 entries against an expected 500. The consumer's subsequent REFRESH_DELETE phase, taking the provider's "nothing changed / here is nothing" at face value, deleted entries the consumer had correctly received from a different, further-along provider - i.e. the incomplete provider's state propagated outward and actively destroyed correct data elsewhere in the mesh, rather than merely failing to advance it. Ruled out The following were each tested directly and found not to be causal: Unclean shutdown / kill -9 : the minimal reproduction above involves no crash of any kind. (A related, but distinct, amplification of the symptom has been observed specifically following kill -9 of two masters in a 3-master mesh - see log evidence #2 above - but the base symptom reproduces without any crash at all.) Network conditions: reproduces at full LAN speed with no induced latency/loss. A WAN emulation profile (25ms±1ms one-way, 0.1% loss via netem ) was used in some runs and disabled in others, with the same outcome either way. ss -ti on a stalled consumer-side connection during one incident showed a healthy TCP session (no retransmits, app_limited , RTT sub-millisecond) - the stall was not at the TCP layer. olcThreads : lowered from the default to 4 on all nodes; no change in outcome. Connection-level timeouts: timeout and network-timeout on the syncrepl directive (both apply only to initial connect/Bind, per slapd-config(5) , not to an established session); olcWriteTimeout (set to 30s server-wide); tcp-user-timeout was considered but not pursued once the TCP-layer health above was confirmed. None of the above affected the outcome. Clock skew: wall-clock time compared across all four nodes, dispatched in parallel via backgrounded SSH; maximum observed spread 123ms, most of which is attributable to SSH connection overhead itself. Reuse of DN namespace across test runs: reproduces with a namespace prefix that has never been used in any prior run (see "Minimal reproduction" above). olcLimits /search size limits: verified unlimited , both per-identity (the mTLS peer DNs used by the syncrepl sessions themselves) and at olcDatabase={-1}frontend,cn=config (i.e. cluster-default). No change in outcome with either configuration. Size of preexisting dataset: reproduces identically against a freshly initialized, otherwise-empty database. Write rate: 5ms and 50ms between successive Add operations produced the same outcome at the same volume thresholds. syncprov-checkpoint interval: tightened from 1000 10 to 50 1 with the affected pair of masters restarted cleanly beforehand; this did not measurably change the outcome across repeated runs. (We had hypothesized, based on the documented behavior that contextCSN is updated in memory on every write but only persisted to the on-disk checkpoint periodically or on clean shutdown, that an unclean shutdown recovering from a stale on-disk checkpoint might explain the crash- correlated variant specifically. Direct testing did not support this; we record the negative result for completeness.) Notes on determinism The symptom is not 100% deterministic at any volume we tested. At 2000 sequential Add operations it has occurred in the substantial majority of our runs; at 1000 in many but not all; at 500 only in a minority of runs, with most runs at that volume converging correctly and instantly (sub-second). We have not identified what distinguishes a failing run from a succeeding one at the same volume and otherwise-identical configuration; every variable we varied to try to explain this (see "Ruled out") produced no change we could attribute to it with confidence. We flag this explicitly because it is the main reason we have not been able to narrow this report further before submitting it. Related discussions we are aware of An openldap-technical mailing list thread from 2008-2009 describes what appears to be the same class of symptom - entries reported by a consumer as superseded ("too old") that were, in fact, never applied - attributed there to out-of-order commit-queue processing on the provider under concurrent writes, with a partial fix referenced against 2.4.11/2.4.16 and a further related ITS (#6619) mentioned as still open as of a 2011 follow-up. We have not been able to confirm whether that specific issue is fully resolved in 2.6.x or whether what we are seeing is a distinct, related condition. ITS #9538 (April 2021, "Accesslog entryCSN ordering is not always monotonous") documents non-monotonic entryCSN ordering under concurrent operations as a live concern in a more recent timeframe. We are aware of, and our architecture already follows, the guidance (Quanah Gibson-Mount, openldap-technical , 24 May 2024) that standard syncrepl is the recommended, safer replication mechanism for multi-provider environments in OpenLDAP 2.6+, in preference to delta-syncrepl . We note this because our minimal reproduction above is, if anything, a simpler case than the multi-provider scenario that guidance addresses (a single provider, a single consumer) and so does not appear to be excluded by it. What we are asking We are not confident enough in any single hypothesis to assert a root cause, and would welcome guidance on: 1. Whether this is a known, already-tracked issue (our searches of the mailing list and public ITS entries did not turn up an exact match, but we may have missed the right terms). 2. Whether a reproduction against a from-source build of current Git master (rather than the Ubuntu package) is a prerequisite for further triage, and if so we are willing to attempt it. 3. Any specific loglevel combination, beyond stats sync (already enabled throughout our testing), or any debugger/instrumentation approach the team would recommend to capture the provider-side state at the exact moment an entry is dropped, which we have not yet managed to capture directly (all evidence above is inferred from surrounding log lines, not a single line that directly shows the drop occurring). We can provide the complete Ansible automation used to build the test environment and drive these reproductions, full logs from any of the runs referenced above, and are happy to run additional targeted tests against specific hypotheses. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2026