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.wi...@ukr.de>
Sent: Thursday, April 3, 2025 12:59 PM
To: Windl, Ulrich <u.wi...@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.wi...@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
