openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

On 1/20/19 4:48 AM, Hallvard Breien Furuseth wrote: > On 1/20/19 2:14 AM, Howard Chu wrote: >> This was the safest approach, considering that a config change could >> alter/remove context out >> from under running threads otherwise. > > No, the safest approach is to fail the 2nd cn=config mod > unless the user says it's OK to block the server. Or fail the 1st cn=config mod too, if that's easier.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

On 1/20/19 2:14 AM, Howard Chu wrote: > Ah, the 2nd cn=config mod has requested a pause, which can't succeed until all > background threads complete. And no new threads will be run while a pause is being requested. Exactly. > This was the safest approach, considering that a config change could alter/remove context out > from under running threads otherwise. No, the safest approach is to fail the 2nd cn=config mod unless the user says it's OK to block the server.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 19 Jan '19

19 Jan '19

Hallvard Breien Furuseth wrote: > On 1/19/19 9:55 PM, h.b.furuseth(a)usit.uio.no wrote: >> On 1/19/19 8:04 PM, Howard Chu wrote: >>> The *server* is not hung. Only modifications to the cn=config DB are blocked. >> >> Yes it is. > > That is, the 2nd mod to cn=config blocks, and that's fine by me, except > _then_ the server is hung. Ah, the 2nd cn=config mod has requested a pause, which can't succeed until all background threads complete. And no new threads will be run while a pause is being requested. This was the safest approach, considering that a config change could alter/remove context out from under running threads otherwise. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

On 1/19/19 9:55 PM, h.b.furuseth(a)usit.uio.no wrote: > On 1/19/19 8:04 PM, Howard Chu wrote: >> The *server* is not hung. Only modifications to the cn=config DB are blocked. > > Yes it is. That is, the 2nd mod to cn=config blocks, and that's fine by me, except _then_ the server is hung. > See the ldapwhoami in my example. And the 'time ldapwhoami' result in output.txt. Sorry, unreadable scripting on my part. Notice the single '&' in ldapmodify & { sleep; ldapwhoami; } That is, ldapmodify in the background and then ldapwhoami. I was pasting to/from the command line, and didn't want the ldapmodify to start until I pressed Return for the ldapwhoami. Thus the weird concatenation.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

On 1/19/19 8:04 PM, Howard Chu wrote: > The *server* is not hung. Only modifications to the cn=config DB are blocked. Yes it is. See the ldapwhoami in my example.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 19 Jan '19

19 Jan '19

Hallvard Breien Furuseth wrote: > Testing again 'subordinate' looks irrelevant. I wonder what I > did in my original and bigger testcase to make it seem relevant. >=20 > On 1/19/19 6:30 PM, Howard Chu wrote: >> This is not really surprising. >=20 > I don't know these interactions well enough to be unsurprised. >=20 > It's not hard to guess that modify(olcDbIndex) might be heavy and > had better be tested.=C2=A0 A simple test says it returns quickly.=C2=A0= I > don't know why the ongoing indexing keeps cn=3Dconfig locked after > the operation succeeded, instead of keeping something in the > indexed DB locked.=C2=A0 I wouldn't expect others to guess that either. modifications to cn=3Dconfig require no other threads to be active. Once = the background indexer starts running, its activity will of course block further cn=3Dconfig mod= ifications until it completes. >> Are you suggesting the indexing task should stop if another config mod= comes in? >=20 > I'm suggesting to fail the 2nd operation if that's what it takes. > Or only hang if the user passes some LDAP control. >=20 > I'm suggesting that config pauses should be brief.=C2=A0 Server hangs > are bad.=C2=A0 Even a crash can be better when other load-balanced > servers can take over.=C2=A0 Not that I'm suggesting that "fix":-) The *server* is not hung. Only modifications to the cn=3Dconfig DB are bl= ocked. You might make a case that background indexing on a backend shouldn't blo= ck writes to unrelated parts of the cn=3Dconfig tree. The current pause desi= gn wouldn't easily support that, but it might be worth working on. Also it's not clea= r which parts of the tree are actually unrelated. E.g., changing schema elements = could affect all backends at once. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

Testing again 'subordinate' looks irrelevant. I wonder what I did in my original and bigger testcase to make it seem relevant. On 1/19/19 6:30 PM, Howard Chu wrote: > This is not really surprising. I don't know these interactions well enough to be unsurprised. It's not hard to guess that modify(olcDbIndex) might be heavy and had better be tested. A simple test says it returns quickly. I don't know why the ongoing indexing keeps cn=config locked after the operation succeeded, instead of keeping something in the indexed DB locked. I wouldn't expect others to guess that either. > Are you suggesting the indexing task should stop if another config mod comes in? I'm suggesting to fail the 2nd operation if that's what it takes. Or only hang if the user passes some LDAP control. I'm suggesting that config pauses should be brief. Server hangs are bad. Even a crash can be better when other load-balanced servers can take over. Not that I'm suggesting that "fix":-)

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 19 Jan '19

19 Jan '19

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard Breien Furuseth > Version: 2.4.47, master > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz > Submission from: (NULL) (193.90.50.50) > > > Use cn=config to add an index to a subordinate database, > then make a 2nd cn=config change. 2nd change waits while > (I assume) indexing, and blocks other slapd operations. > So ldapwhoami during 2nd change takes 5 seconds. > > To reproduce: ./bug.sh > To debug, attach gdb in another terminal during 2nd MOD. > gdb -q ../servers/slapd/slapd `cat slapd.pid` > > trace.txt shows the 2nd config_back_modify() waiting > in slap_pause_server(). This is not really surprising. Are you suggesting the indexing task should stop if another config mod comes in? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 18 Jan '19

18 Jan '19

Full_Name: Hallvard Breien Furuseth Version: 2.4.47, master OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz Submission from: (NULL) (193.90.50.50) Use cn=config to add an index to a subordinate database, then make a 2nd cn=config change. 2nd change waits while (I assume) indexing, and blocks other slapd operations. So ldapwhoami during 2nd change takes 5 seconds. To reproduce: ./bug.sh To debug, attach gdb in another terminal during 2nd MOD. gdb -q ../servers/slapd/slapd `cat slapd.pid` trace.txt shows the 2nd config_back_modify() waiting in slap_pause_server().

1 0

(ITS#8957) Handling of TLS in async mode
by vsmith＠interlinknetworks.com 14 Jan '19

14 Jan '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:8d9a:95ec:46f9:30fd) I looked at the release notes and there have been a few issues with Async mode with TSL in 2.4. I had been using 2.3.20 with my own patches to make Async mode with TLS work with my aplication. I need to upgrade to 2.4 but I have tried many version of it and none have worked. The basic issue is that the TLS code is never called so LDAPS connections fail. My symptoms are very similar to the bug report that caused a fix in 2.4.26 but 2.4.26 is not working for me. I see the same issue with 2.4.47. If I don't use LDAP_OPT_CONNECT_ASYNC then the connection works and I get this trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 3 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:unknown state TLS certificate verification: depth: 1, err: 0, subject: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=Michigan/L=Ann Arbor/O=Interlink Networks Services, LLC./OU=Quality Assurance/CN=test.interlinknetworks.com/emailAddress=QAtest@interlinknetwor…, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state ldap_open_defconn: successful ldap_send_server_request But with LDAP_OPT_CONNECT_ASYNC enabled I never see the TLS code called and the connection fails. The trace is: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: -1 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request ... ldap_result ld 0x9bd6f70 msgid 1 wait4msg ld 0x9bd6f70 msgid 1 (timeout 0 usec) wait4msg continue ld 0x9bd6f70 msgid 1 all 1 ** ld 0x9bd6f70 Connections: * host: test.interlinknetworks.com port: 636 (default) refcnt: 2 status: Connected last used: Mon Jan 14 15:33:57 2019 ** ld 0x9bd6f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9bd6f70 request count 1 (abandoned 0) ** ld 0x9bd6f70 Response Queue: Empty ld 0x9bd6f70 response count 0 ldap_chkResponseList ld 0x9bd6f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x9bd6f70 NULL ldap_int_select read1msg: ld 0x9bd6f70 msgid 1 all 1 ber_get_next failed. ldap_err2string ... Can't contact LDAP server Thanks, Vern

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs