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/servers/slapd/main.c?ref_type=tags#L741
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,
--
Bastian Tweddell
Juelich Supercomputing Centre
phone: +49 (2461) 61-6586
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Dr. Stephanie Bauer (stellvertretende Vorsitzende),
Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
