Hi!
I'm still fighting with the issue. When having trace enabled, I see this when slapd stops responding: Apr 17 11:30:15 v05 slapd[14751]: slap_listener_activate(9): Apr 17 11:30:15 v05 slapd[14751]: >>> slap_listener(ldapi:///) Apr 17 11:30:15 v05 slapd[14751]: connection_get(11): got connid=1004 Apr 17 11:30:15 v05 slapd[14751]: connection_read(11): checking for input on id=1004 Apr 17 11:30:15 v05 slapd[14751]: op tag 0x60, time 1744882215 Apr 17 11:30:15 v05 slapd[14751]: conn=1004 op=0 do_bind Apr 17 11:30:15 v05 slapd[14751]: >>> dnPrettyNormal: <> Apr 17 11:30:15 v05 slapd[14751]: <<< dnPrettyNormal: <>, <> Apr 17 11:30:15 v05 slapd[14751]: do_bind: dn () SASL mech EXTERNAL Apr 17 11:30:15 v05 slapd[14751]: ==>slap_sasl2dn: converting SASL name gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN Apr 17 11:30:15 v05 slapd[14751]: ==> rewrite_context_apply [depth=1] string='gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' Apr 17 11:30:15 v05 slapd[14751]: ==> rewrite_rule_apply rule='gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' string='gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' [1 pass(es)] Apr 17 11:30:15 v05 slapd[14751]: ==> rewrite_context_apply [depth=1] res={0,'dn:cn=config'} Apr 17 11:30:15 v05 slapd[14751]: slap_parseURI: parsing dn:cn=config Apr 17 11:30:15 v05 slapd[14751]: >>> dnNormalize: <cn=config> Apr 17 11:30:15 v05 slapd[14751]: <<< dnNormalize: <cn=config> Apr 17 11:30:15 v05 slapd[14751]: <==slap_sasl2dn: Converted SASL name to cn=config Apr 17 11:30:15 v05 slapd[14751]: slap_sasl_getdn: dn:id converted to cn=config Apr 17 11:30:15 v05 slapd[14751]: SASL Authorize [conn=1004]: proxy authorization allowed authzDN="" Apr 17 11:30:15 v05 slapd[14751]: send_ldap_sasl: err=0 len=-1 Apr 17 11:30:15 v05 slapd[14751]: do_bind: SASL/EXTERNAL bind: dn="cn=config" bind_ssf=0 Apr 17 11:30:15 v05 slapd[14751]: send_ldap_response: msgid=1 tag=97 err=0 Apr 17 11:30:15 v05 slapd[14751]: <== slap_sasl_bind: rc=0 Apr 17 11:30:15 v05 slapd[14751]: connection_get(11): got connid=1004 Apr 17 11:30:15 v05 slapd[14751]: connection_read(11): checking for input on id=1004 Apr 17 11:30:15 v05 slapd[14751]: op tag 0x68, time 1744882215 Apr 17 11:30:15 v05 slapd[14751]: conn=1004 op=1 do_add Apr 17 11:30:15 v05 slapd[14751]: >>> dnPrettyNormal: <olcOverlay={0}syncprov,olcDatabase={0}config,cn=config> Apr 17 11:30:15 v05 slapd[14751]: <<< dnPrettyNormal: <olcOverlay={0}syncprov,olcDatabase={0}config,cn=config>, <olcOverlay={0}syncprov,olcDatabase={0}config,cn=config> Apr 17 11:30:15 v05 slapd[14751]: oc_check_required entry (olcOverlay={0}syncprov,olcDatabase={0}config,cn=config), objectClass "olcSyncProvConfig" Apr 17 11:30:15 v05 slapd[14751]: oc_check_allowed type "objectClass" Apr 17 11:30:15 v05 slapd[14751]: oc_check_allowed type "olcOverlay" Apr 17 11:30:15 v05 slapd[14751]: oc_check_allowed type "structuralObjectClass" Apr 17 11:30:15 v05 slapd[14751]: slap_get_csn: conn=1004 op=1 generated new csn=20250417093015.246123Z#000000#005#000000 manage=1 Apr 17 11:30:15 v05 slapd[14751]: slap_queue_csn: queueing 0x7f7fb8121a00 20250417093015.246123Z#000000#005#000000 Apr 17 11:30:15 v05 slapd[14751]: syncprov_db_open: starting syncprov for suffix cn=config Apr 17 11:30:15 v05 slapd[14751]: conn=-1 op=0 syncprov_findcsn: mode=FIND_MAXCSN csn=
Kind regards, Ulrich Windl
From: Windl, Ulrich u.windl@ukr.de Sent: Thursday, April 3, 2025 12:59 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical@openldap.org Subject: RE: Adding syncprov overlay to cn=config seems to freeze the server
Hi!
Updates:
1. Even when I add the missing "olcOverlay: {0}syncprov" it does not change a thing 2. When using slapmodify instead of ldapmodify to do the change offline, it succeeds and slapd starts after that 3. Adding a syncprov overlay to another database online also worked.
Kind regards, Ulrich Windl
From: Windl, Ulrich u.windl@ukr.de Sent: Thursday, April 3, 2025 10:52 AM To: openldap-technical@openldap.org Subject: [EXT] Adding syncprov overlay to cn=config seems to freeze the server
Hi!
I'm trying to script a reconfiguration of out OpenLDAP servers, also changing the replication details. After dropping the old syncrepl overlay, I tried to add a new one like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig
I deliberately did not add more specific attributes, because I wanted to add them later. However I forgot to set olcOverlay.
The point is that both, ldapmodify and slapd become unresponsive using that LDIF, at least when provided as ldapmodify -Y EXTERNAL -H ldapi:/// <<LDIF ... LDIF
Is this a bug?
Seen in OpenLDAP 2.5 provided by SLES15 SP6. From a coredump I forced, I see that the threads are all waiting, using one of these: __pthread_clockjoin_ex pthread_cond_wait __pthread_clockjoin_ex
Kind regards, Ulrich Windl