On Thu, Feb 12, 2026 at 10:31:41AM +0100, Bastian Tweddell wrote:
>> Just to check: how are you changing the configuration? Are you sure
>> you're changing the config DB online (ldapmodify etc.) and not changing
>> it via **offline** tools like slapmodify or worse editing the files
>> directly (which the files themselves tell you **not** to do)?
>
> The cn=config db is modified through an ldap connection. I use ansible
> to deploy a container (podman/k8s) which runs slapd, and when in
> bootstrap mode, ansible also deploys the cn=config in a second step. The
> connections and ops are logged:
> ```
> conn=1013 fd=9 ACCEPT from IP=10.88.0.1:35984 (IP=0.0.0.0:1389)
> conn=1013 op=0 BIND dn="cn=admin,cn=config" method=128
> conn=1013 op=0 BIND dn="cn=admin,cn=config" mech=SIMPLE bind_ssf=0 ssf=0
> conn=1013 op=0 RESULT tag=97 err=0 qtime=0.000015 etime=0.024610 text=
> conn=1013 op=1 SRCH base="olcDatabase={1}mdb,cn=config" scope=0 deref=0
> filter="(objectClass=*)"
> conn=1013 op=1 SRCH attr=olcSyncrepl
> conn=1013 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.000124
> nentries=1 text=
> conn=1013 op=2 MOD dn="olcDatabase={1}mdb,cn=config"
> conn=1013 op=2 MOD attr=olcSyncrepl
> slap_get_csn: conn=1013 op=2 generated new
> csn=20260211083409.540023Z#000000#000#000000 manage=1
> slap_queue_csn: queueing 0x7f92b81296e0
> 20260211083409.540023Z#000000#000#000000
> Config: ** successfully added syncrepl rid=001 "ldaps://PROVIDER01"
> Config: ** successfully added syncrepl rid=002 "ldaps://PROVIDER02"
> conn=1013 op=2 RESULT tag=103 err=0 qtime=0.000005 etime=0.000438 text=
> slap_graduate_commit_csn: removing 0x7f92b81296e0
> 20260211083409.540023Z#000000#000#000000
> conn=1013 op=3 UNBIND
> conn=1013 fd=9 closed
> ```
> Ansible uses python-ldap on the target system.
Interesting, what if you up the loglevel then (at least add sync into
the mix, but more the better)? Also when it's not doing anything, can
you attach gdb to it and see what it's doing whether it's truly idle?
And it's happily handling other traffic just fine in the meantime?
>> Doesn't SIGUSR1 just kill the process, so your service manager starts a
>> new one that you see do this?
>
> USR1 triggers a `slap_sig_wake`:
> https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_12/servers/slapd/main.c?ref_type=tags#L741
> slapd is not stopped and restarted.
Sorry, I completely forgot slapd did that.
> Waiting before adding the syncrepl config also does not make a
> difference, as you said.
>
> If you are curious why this happens, I would like to provide more info
> and dive in a bit deeper. But I can also work around this issue on my
> end.
Possibly, if you can set up something reproducible, as I said it
shouldn't happen so smells like a bug worth investigating.
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
