Hi all,
I have a question, if there is way that slapd automatically starts syncreplication after it was added to OLC.
When installing a fresh slapd with olc config, it starts up with a bootstrap-olc. In the following step the bootstrap process (ansible) reconfigures mostly everything in cn=config, adding globals, ALCs, schema and the main MDB.
As soon as the MDB database gets its syncrepl config, the log states it was successful: ``` Config: ** successfully added syncrepl rid=001 "ldaps://PROVIDER01.HOST" Config: ** successfully added syncrepl rid=002 "ldaps://PROVIDER02.HOST" ```
But after that the connections to the providers are not established. Even after waiting way longer then the configured timeout:
``` olcSyncrepl: {0}rid="001" provider="ldaps://PROVIDER01.HOST bind dn="DN_CONSUMER" bindmethod="simple" creden tials="SECRET" filter="(objectclass=*)" keepalive="180:9:75" retry= "20 3 60 10 300 +" schemachecking="on" searchbase="BASEDN " type="refreshAndPersist" olcSyncrepl: {1}rid="002" provider="ldaps://PROVIDER01.HOST bind dn="DN_CONSUMER" bindmethod="simple" creden tials="SECRET" filter="(objectclass=*)" keepalive="180:9:75" retry= "20 3 60 10 300 +" schemachecking="on" searchbase="BASEDN " type="refreshAndPersist" ```
I have to either restart the service or send slapd a SIGUSR1. Is there a way to configure the syncrepl via OLC so that the syncrepl process is initiated automatically when it was added?
Many thanks,
On Mon, Feb 09, 2026 at 09:45:10AM +0100, Bastian Tweddell wrote:
Hi all,
I have a question, if there is way that slapd automatically starts syncreplication after it was added to OLC.
When installing a fresh slapd with olc config, it starts up with a bootstrap-olc. In the following step the bootstrap process (ansible) reconfigures mostly everything in cn=config, adding globals, ALCs, schema and the main MDB.
As soon as the MDB database gets its syncrepl config, the log states it was successful:
Config: ** successfully added syncrepl rid=001 "ldaps://PROVIDER01.HOST" Config: ** successfully added syncrepl rid=002 "ldaps://PROVIDER02.HOST"But after that the connections to the providers are not established. Even after waiting way longer then the configured timeout:
They should get scheduled straight away. If you enable 'sync' level logging, what do the logs say about what's happening?
Regards,
On 09Feb26 11:22+0100, Ondřej Kuzník wrote:
They should get scheduled straight away. If you enable 'sync' level logging, what do the logs say about what's happening?
Adding 'sync' to the loglevel does not cause more log lines.
But, when sending sigusr1 to slapd, sync-logs begin immediately: ``` do_syncrep1: rid=002 starting refresh (sending cookie=rid=002) syncrepl_message_to_entry: rid=002 DN: BASEDN, UUID: 813cd5d4-88d1-1038-96ad-bf796e276721 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f07ab7f8640 syncrepl_entry: rid=002 inserted UUID 813cd5d4-88d1-1038-96ad-bf796e276721 syncrepl_entry: rid=002 be_search (32) ... ```
The provisioning process adds the database section in two steps, first the main databse config (suffix, rootdn etc), and in a second step the syncrepl config. Would it make sense to add a delay before adding the syncrepl configuration to the database section?
Many thanks,
On 09Feb26 16:13+0100, Bastian Tweddell wrote:
On 09Feb26 11:22+0100, Ondřej Kuzník wrote:
They should get scheduled straight away. If you enable 'sync' level logging, what do the logs say about what's happening?
Adding 'sync' to the loglevel does not cause more log lines.
I am running 2.6.9 currently. I missed that in the first mail. Let me know if I should debug more.
Thanks,
On Mon, Feb 09, 2026 at 04:13:28PM +0100, Bastian Tweddell wrote:
On 09Feb26 11:22+0100, Ondřej Kuzník wrote:
They should get scheduled straight away. If you enable 'sync' level logging, what do the logs say about what's happening?
Adding 'sync' to the loglevel does not cause more log lines.
Hi Bastian, this is contrary to what I've seen every time I've done this before.
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)?
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?
do_syncrep1: rid=002 starting refresh (sending cookie=rid=002) syncrepl_message_to_entry: rid=002 DN: BASEDN, UUID: 813cd5d4-88d1-1038-96ad-bf796e276721 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f07ab7f8640 syncrepl_entry: rid=002 inserted UUID 813cd5d4-88d1-1038-96ad-bf796e276721 syncrepl_entry: rid=002 be_search (32) ...The provisioning process adds the database section in two steps, first the main databse config (suffix, rootdn etc), and in a second step the syncrepl config. Would it make sense to add a delay before adding the syncrepl configuration to the database section?
Shouldn't make a difference, in fact, both scenarios (DB+syncrepl in one go or separately) are being actively tested in our test suite.
Regards,
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,
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 closedAnsible 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/se... 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,
On Thu, Feb 12, 2026 at 12:09:50PM +0100, Ondřej Kuzník wrote:
On Thu, Feb 12, 2026 at 10:31:41AM +0100, Bastian Tweddell wrote:
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: [...] 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? [...] Possibly, if you can set up something reproducible, as I said it shouldn't happen so smells like a bug worth investigating.
Also smells like ITS#9878, especially if things clear up after any new traffic comes in. Unfortunately this one couldn't be fixed in 2.6 but 2.7 handles these properly.
If it indeed is ITS#9878, just using cn=monitor which you want to interact with in production deployments will probably make sure you never get stuck like this.
Regards,
Dear Ondřej,
On 12Feb26 12:34+0100, Ondřej Kuzník wrote:
Possibly, if you can set up something reproducible, as I said it shouldn't happen so smells like a bug worth investigating.
Today, I could pin down the issue to a mistake in the configuration of slapd. The TLS part was setup incorrectly which let slapd wait. I fixed the config and syncrepl begins immediately to sync data after it was added.
Many Thanks,
openldap-technical@openldap.org
-
Bastian Tweddell -
Ondřej Kuzník