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

Ondřej,

thanks, I'll try to get the patch integrated to the version I'm using, and I'll report back.

Kind regards, Ulrich Windl

-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Thursday, April 17, 2025 11:42 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Adding syncprov overlay to cn=config seems to freeze the server Importance: High

On Thu, Apr 17, 2025 at 09:35:45AM +0000, Windl, Ulrich wrote:

...

Hi!

I'm still fighting with the issue. When having trace enabled, I see this when slapd stops responding:

Hi Ulrich, reports of crashes and lockups should be reported to the ITS more so when repeatable, I had done so a few days ago[0], and we have a patch now you can test with.

[0]. https://bugs.openldap.org/show_bug.cgi?id=10327

Regards,

-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP