Dear Ondřej,
On 09Feb26 17:29+0100, Ondřej Kuzník wrote:
this is contrary to what I've seen every time I've done this before.
I understand. On my testsystem it works as you say. The syncrepl begins immediately. On the production systems, the syncrepl hangs after it was added. There is no clear difference to me, on both I use the identical build of slapd (container).
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.
But, when sending sigusr1 to slapd, sync-logs begin immediately:
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/se... slapd is not stopped and restarted.
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.
Many thanks,