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:

Even when I add the missing “olcOverlay: {0}syncprov” it does not change a thing
When using slapmodify instead of ldapmodify to do the change offline, it succeeds and slapd starts after that
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