openldap-bugs August 2026

openldap-bugs@openldap.org

1 participants
214 discussions

[Issue 10576] New: modify dn is not logged when STATS2 is on
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10576 Issue ID: 10576 Summary: modify dn is not logged when STATS2 is on Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ITS#9042 hid the line in the else branch, it should be outside the if with a STATS|STATS2 filter. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10574] New: request_process can desync
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10574 Issue ID: 10574 Summary: request_process can desync Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Failing to allocate an upstream on a "write" tagged op, c_restricted_inflight is not incremented but o_restricted still claims op's cone of focus is WRITE, freeing that op then decrements counter spuriously. We need to reset o_restricted if we didn't commit the restrictions on the rejection paths. Related to ITS#10510, which only closed one half of the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10561] New: multiple logging.c minor issues
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10561 Issue ID: 10561 Summary: multiple logging.c minor issues Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dontbugme.relocate646(a)slmail.me Target Milestone: --- Created attachment 1185 --> https://bugs.openldap.org/attachment.cgi?id=1185&action=edit servers/slapd/logging.c surprising behaviors # OpenLDAP `slapd` log-file engine — observed bugs and pitfalls This document lists defects and surprising behaviors identified by reading `servers/slapd/logging.c` (the `logfile`, `logfile-format`, `logfile-only` and `logfile-rotate` implementation) in this tree. All line references point to that file. > Scope: these concern the **internal** log file that `slapd` writes itself when > `logfile <path>` is configured. They are independent of `rsyslogd`/`syslog-ng`. --- ## Bug 1 — `loglevel`/`olcLogLevel` messages are *not* written to the logfile unless `logfile-only on` ### What happens `slapd` maintains two separate diagnostic streams: * the **debug stream** (`slap_debug`), fed by the `-d` command-line flag, and * the **syslog stream** (`ldap_syslog`), fed by `loglevel`/`olcLogLevel` (and `-s`). The internal log file is written **only** from the debug stream. The actual write is done in `slap_debug_print()`, which is the `LBER_OPT_LOG_PRINT_FN` callback fired for every `ber_log*` message whose level passes `slap_debug` (`logging.c:138` and `:222`). Messages that only pass `ldap_syslog` are emitted through `syslog()` and never reach the file. `logfile-only` controls this: * `logfile-only off` (default): `slap_debug_print()` also writes to stderr (`:135`), and syslog messages stay in syslog — **they never land in the file**. * `logfile-only on`: `slap_syslog_set()` ORs the syslog level into `slap_debug` and zeroes `ldap_syslog` (`:571-581`, `:807-819`, `:593-600`), so syslog messages now flow into the file — **but syslog itself is disabled**. So there is **no configuration that writes *both* syslog and a complete log file**. Setting `logfile` + `loglevel stats` is the trap most operators fall into: stats go to syslog, and the file stays empty (unless you also used `-d` or `logfile-only on`). ### How to reproduce `slapd.conf` (or `cn=config` equivalent): ``` logfile /tmp/slapd.log loglevel stats # (no -d flag, no logfile-only) ``` 1. Start `slapd -f slapd.conf -h "ldap://:3899/"` (do **not** pass `-d`). 2. Bind / search a few times. 3. Inspect the file: ```sh cat /tmp/slapd.log # empty (or only the startup Versionstr line) journalctl -t slapd # shows "conn=N op=M ... RESULT" stats lines ``` 4. Stop, add `logfile-only on`, restart, repeat. Now: ```sh cat /tmp/slapd.log # stats lines ARE present journalctl -t slapd # stats lines are GONE (syslog disabled) ``` ### Severity High for operators expecting `logfile` + `loglevel` to mirror syslog. The behavior is by design but undocumented as a limitation. --- ## Bug 2 — Stale PID in syslog-style log prefixes (`getpid()` captured before `fork()`) ### What happens When `logfile-format` is one of the syslog-style values (`syslog-utc`/`syslog-localtime`/`rfc3339-utc`), the prefix string `"<host> <prog>[<pid>]: "` is built **once**, at config-parse time, inside the `CFG_LOGFILE_FORMAT` handler (`logging.c:852-856`): ```c splen = sprintf( syslog_prefix, "%s %s %s[%d]: ", ..., serverName, getpid() ); ``` `config_logging()` runs while `slapd` is still the original process. `slapd` then daemonizes (`slapd_daemon()` forks), so the child that actually does the logging has a **different PID** than the one baked into `syslog_prefix`. Every line in the file therefore shows the pre-fork parent PID, not the PID of the running daemon. ### How to reproduce `slapd.conf`: ``` logfile /tmp/slapd.log logfile-format syslog-localtime loglevel stats ``` 1. Start `slapd` in daemon mode (default): `slapd -f slapd.conf -h "ldap://:3899/"`. 2. Find the real daemon PID: ```sh pidof slapd cat /run/slapd/slapd.pid # or wherever pidfile points ``` 3. Trigger a line (any search) and look at the prefix in the file: ```sh head -3 /tmp/slapd.log # e.g. Aug 05 10:40:12 host slapd[1234]: conn=1 ... ``` `1234` is the PID of the short-lived parent, not the daemon PID printed by `pidof slapd`. ### Severity Medium. Cosmetic for single-instance setups, but misleading for log analysis / process correlation and for systems that run `slapd` under a supervisor that expects the logged PID to match the supervised process. --- ## Bug 3 — `logfile-format default` is identical to `logfile-format debug` ### What happens The log-file header is only rebuilt when `logfile_format > LFMT_DEBUG` (`logging.c:185`). For `LFMT_DEFAULT` (value `0`) and `LFMT_DEBUG` (value `1`) the `iov[0]` debug prefix (`"%lx.<frac> <pthread> "`, built at `:130`) is used verbatim. So: * `default` → raw `epoch.hex <threadptr> ` prefix, **no** date, **no** hostname, **no** PID; * `debug` → exactly the same. The name `default` suggests a "normal" syslog-like line, but it is just the `-d`-style debugging prefix. The only formats that actually add a timestamp / host / PID header are `syslog-utc`, `syslog-localtime` and `rfc3339-utc`. ### How to reproduce ``` logfile /tmp/default.log logfile-format default loglevel stats # (separate run) logfile /tmp/debug.log logfile-format debug loglevel stats ``` Run `slapd`, trigger one operation in each, then `diff`: ```sh head -1 /tmp/default.log; head -1 /tmp/debug.log # byte-identical prefixes ``` ### Severity Low. Documentation/naming clarity issue; can surprise anyone expecting human-readable timestamps from the default format. --- ## Bug 4 — Rotation numbered-shift runs outside the mutex (lost backups under load) ### What happens Rotation is split in two: 1. Under `logfile_mutex` (`:140-183`): the current file is renamed to `<path>.tmp` (`:147-148`) and a fresh file is reopened (`:166`). 2. **After** the mutex is released (`:227`), the numbered-shift loop runs (`:229-238`): it renames `<path>.tmp` → `<path>.NN` and shifts older `<path>.NN` → `<path>.N(N+1)`. Because step 2 executes outside the lock, two (or more) threads that both tripped the size/age threshold can interleave: ``` T1: under lock -> rename current -> .tmp ; reopen ; unlock T2: under lock -> rename NEW current -> .tmp ; reopen ; unlock T1: outside lock-> rename .tmp -> .NN (this .tmp is actually T2's rotated file) T2: outside lock-> rename .tmp -> .NN (no .tmp exists anymore -> rename() fails, the backup T2 meant to keep is lost) ``` Consequences under heavy concurrent logging near the rotation threshold: * a rotated backup can be silently overwritten / lost, and * `rename()` is called on a `.tmp` that no longer exists (returns `-1`, ignored). The trigger-to-`.tmp` step is safe (under the lock) but the hand-off to the outside-lock shift is racy because the shared `.tmp` name is reused by every rotation event. ### How to reproduce (best-effort, not deterministic) ``` logfile /tmp/slapd.log logfile-format debug logfile-rotate 5 1 0 # 5 backups, 1 MB size limit, no age limit loglevel any # enable verbose categories ``` Drive a very high-volume debug stream so the file crosses 1 MB repeatedly in a short window (e.g. `loglevel sync stats packets` plus a busy replication session, or a tight loop of anonymous binds). Then list backups: ```sh ls -la /tmp/slapd.log* ``` Expected: `.01` … `.05` present and strictly ordered by age. Observed under load: gaps (e.g. `.01 .02 .04 .05` with `.03` missing) or a rotation where the oldest retained copy is newer than it should be, indicating a backup was clobbered by a racing rotation. > Note: because the race is timing-dependent, run the load several times; the > failure is intermittent, which is itself the signature of a lock-ordering bug. ### Severity Low-to-medium. Only matters with `logfile-rotate` enabled and very high log volume. Data-loss is of rotated *backups*, not of the live log. --- ## Bug 5 — Age-based rotation uses inode change time, not file create/modify time ### What happens When a file is (re)opened, the rotation "birth" timestamp is taken from `st_ctime` (`logging.c:287`): ```c logfile_fcreated = st.st_ctime; /* not strictly true but close enough */ ``` The comment admits the approximation. `st_ctime` changes on *any* inode metadata change (chmod, chown, rename, truncate, `touch -c`), not just content creation. Age-based rotation (`logfile-rotate <max> <MB> <hours>`) therefore measures the interval since the last inode-changing event, which can be reset by an external tool (logrotate `copytruncate`, backup, permission change) and produce an unexpectedly early or late rotation. ### How to reproduce ``` logfile /tmp/slapd.log logfile-format debug logfile-rotate 3 0 1 # rotate every 1 hour (no size limit) loglevel stats ``` 1. Start `slapd`; note the time. 2. Before the hour elapses, touch the inode metadata externally: ```sh touch /tmp/slapd.log # updates ctime (open with O_TRUNC not needed) ``` 3. Watch rotation: it can fire based on the *touch* time rather than the daemon's own start/last-write time, because `logfile_fcreated` reflects `ctime`. ### Severity Low. Edge-case affecting operators who let an external tool also touch the logfile. --- ## Summary table | # | Bug | Config affected | Effect | Can lose data? | |---|-----|-----------------|--------|----------------| | 1 | `loglevel` not written to file unless `logfile-only on` | `logfile`+`loglevel` | file misses syslog-level messages | no (silent gap) | | 2 | Stale PID in syslog-style prefixes | `logfile-format syslog-*`/`rfc3339-*` | wrong `[pid]` in every line | no | | 3 | `default` == `debug` output | `logfile-format default` | no timestamp/host/pid header | no | | 4 | Rotation shift outside mutex | `logfile-rotate` under load | lost/overwritten backups | yes (backups only) | | 5 | Age rotation uses `ctime` | `logfile-rotate … <hours>` | wrong rotation timing | no | --- ## Workarounds * To get `loglevel` content in the file, use `logfile-only on` **and** accept that native syslog logging is then disabled — or run `slapd -d <level>` instead of `loglevel`, or keep `rsyslogd` as the file writer. * For correct per-line PID/timestamps, prefer `logfile-format rfc3339-utc` (still has the stale-PID issue from Bug 2, but at least a real timestamp). * Avoid relying on `logfile-rotate` for audit-grade retention under very high log volume; use an external log rotator that copies and truncates, or pipe to `rsyslogd`. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10571] New: Asyncmeta's conn-ttl optional reset-interval argument silently defaults to the TTL
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10571 Issue ID: 10571 Summary: Asyncmeta's conn-ttl optional reset-interval argument silently defaults to the TTL Product: OpenLDAP Version: 2.7.0 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: --- mc->mc_conn_reset_interval is set to TTL if the 1 argument form is configured (no value for <interval> provided) but as per manpage it should default to `1` instead. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10568] New: Client tools segfault when run without arguments
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10568 Issue ID: 10568 Summary: Client tools segfault when run without arguments Product: OpenLDAP Version: 2.7.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: nzb_tuxxx(a)proton.me Target Milestone: --- When the default connection fails, several client tools call `strlen(ldapuri)` while `ldapuri` is `NULL`. Steps to reproduce: 1. Run `ldapadd`, `ldapdelete`, `ldapmodify`, `ldapmodrdn`, `ldappasswd`, `ldapsearch`, `ldapvc`, or `ldapwhoami` without arguments. 2. Observe `Segmentation fault (core dumped)` and exit status 139. References: - Regression: https://git.openldap.org/openldap/openldap/-/commit/37d677fb8d16b05a387c9f9… - Downstream report: https://gitlab.archlinux.org/archlinux/packaging/packages/openldap/-/work_i… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10564] A single anonymous LDAP search with a crafted server-side-sort control heap-overflows the OpenLDAP slapd worker
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10564 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 4846d7e3 by Howard Chu at 2026-08-10T16:36:31+01:00 ITS#10564 slapo-sssvlv: tighten sss_parseCtrl RE27: • f92a2e17 by Howard Chu at 2026-08-20T21:02:57+00:00 ITS#10564 slapo-sssvlv: tighten sss_parseCtrl RE26: • 6c0323aa by Howard Chu at 2026-08-20T21:07:39+00:00 ITS#10564 slapo-sssvlv: tighten sss_parseCtrl -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10575] New: MDB_WRITEMAP commit fails on Windows without MDB_NOSYNC on 1.0.1
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10575 Issue ID: 10575 Summary: MDB_WRITEMAP commit fails on Windows without MDB_NOSYNC on 1.0.1 Product: LMDB Version: 1.0.1 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 1194 --> https://bugs.openldap.org/attachment.cgi?id=1194&action=edit reproducer On Windows, an environment opened with MDB_WRITEMAP cannot commit a write transaction unless MDB_NOSYNC or MDB_NOMETASYNC is also set. mdb_txn_commit() fails with ERROR_INVALID_HANDLE. See attached for reproducer. This does not impact Linux, MacOS, or the .9.* series. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10572] New: please add mdb_env_get_maxkeysize() to upgrading.doc for 1.0.x
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10572 Issue ID: 10572 Summary: please add mdb_env_get_maxkeysize() to upgrading.doc for 1.0.x Product: LMDB Version: 1.0.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: matthias.andree(a)gmx.de CC: steffen(a)sdaoden.eu Target Milestone: --- https://git.openldap.org/openldap/openldap/-/commit/136667a1492ea624b8d8bee… updated the mdb_env_get_maxkeysize() documentation for the LMDB_1.0.1 release such that it now correctly mentions it must be called after mdb_env_open() rather than mdb_env_create() (as was sufficient in 0.9.x), in response to a defect report from Steffen here https://bugs.openldap.org/show_bug.cgi?id=10534. Please add a relevant line that mdb_env_get_maxkeysize() can now (as of 1.0.0) only be called after mdb_env_open() to upgrading.doc so that LMDB users are aware they may need to move the mdb_env_get_maxkeysize() call in their code. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10569] New: Makefile, lmdb.pc file show version 1.0.0
by openldap-its＠openldap.org 21 Aug '26

21 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10569 Issue ID: 10569 Summary: Makefile, lmdb.pc file show version 1.0.0 Product: LMDB Version: 1.0.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: trivial Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The LMDB_VERSION in the Makefile wasn't updated. Makefile will be patched to obtain the version from the built binaries. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9042] loglevel setting that allows seeing attribute values for MOD operations
by openldap-its＠openldap.org 19 Aug '26

19 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9042 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10576 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2026