openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

(ITS#6106) Unable to start LDAP Service in Windows
by Jemmy.Sentonius＠infor.com 10 May '09

10 May '09

Full_Name: Jemmy Sentonius Version: 2.2.29 OS: Windows 2003 Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (211.24.230.162) 1) Start the LDAP Service in Windows (logon as Domain Administrator) 2) System will prompt error: Windows could not start the InforSecurity LDAP on local computer. For more information, review the system event log. If this is non-Microsoft Service, contact the service vendor, and refer to service-specific error code 16. 3) Go to Windows Event Viewer, System Log Notice that there's an error log with description: The InforSecurity LDAP Service terminated with service-specific error 16 (0x10)

1 0

Re: (ITS#6104) race condition with cancel operation
by hyc＠symas.com 10 May '09

10 May '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for > the canceled operation to obey o_abandon before o_cancel gets set. Cancel is just best-effort, why not just set o_cancel before o_abandon? > Though I had to insert some sleeps to achieve that. > Either the operation is abandoned and the Cancel operation receives > tooLate, or if the client unbinds/closes the connection fast enough > Cancel will hang: slapd does not close the connection, and hangs on > shutdown: "slapd shutdown: waiting for 1 operations/tasks to finish". > > Since the flags are not mutex-protected (at least not when read), it's > not enough to move the o_cancel setting after o_abandon in the Cancel > thread. The cancelled thread might still see the o_abandon change > first. A fix could be to make o_abandon a bitmask which says whether > the abandon is actually a cancel, but the Abandon and Cancel operations > will still need a mutex to coordinate so that Abandon does not reset > a Cancel bitflag. In any case, it'd be cleaner if an operation which > reacts to o_abandon grabs some mutex before checking o_cancel. > > > The problem was tested as follows: > - sleep 0.2 sec after Statslog "DEL" and before setting SLAP_CANCEL_REQ. > - log "ABANDONED" when send_ldap_response() abandons the operation. > - Client: A python socket client which sends raw BER, no libldap: > s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > s.connect(('localhost', 3890)) > s.send(delete("cn=test")) > time.sleep(0.1) > s.send(cancel()) # cancel last operation > #sys.exit() > time.sleep(0.4) > s.send(unbind()) > --> > conn=0 fd=9 ACCEPT from IP=127.0.0.1:56945 (IP=127.0.0.1:3890) > conn=0 op=0 DEL dn="cn=test" > conn=0 op=1 EXT oid=1.3.6.1.1.8 > conn=0 op=1 CANCEL msg=1 > conn=0 op=0 ABANDONED > conn=0 op=2 UNBIND > conn=0 op=1 RESULT oid= err=120 text= > conn=0 fd=9 closed > <server closed connection, client exited> > ^C slapd > > If the client exits after send(cancel()): > conn=0 fd=9 ACCEPT from IP=127.0.0.1:48826 (IP=127.0.0.1:3890) > conn=0 op=0 DEL dn="cn=test" > conn=0 op=1 EXT oid=1.3.6.1.1.8 > conn=0 op=1 CANCEL msg=1 > conn=0 op=2 UNBIND > conn=0 op=0 ABANDONED > <not closing connection> > ^C slapd > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 1 operations/tasks to finish > <slapd is hanging> > kill -KILL<slapd> > > slapd.conf: > include servers/slapd/schema/core.schema > allow update_anon > database ldif > directory "." > suffix "cn=test" > > Patches to slapd: > > Index: cancel.c > --- cancel.c 21 Jan 2009 23:40:25 -0000 1.30 > +++ cancel.c 11 May 2009 04:42:58 -0000 > @@ -92,4 +92,8 @@ > } > > + { > + struct timeval timeout = { 0, 200000 }; > + select(0, NULL, NULL, NULL,&timeout); > + } > o->o_cancel = SLAP_CANCEL_REQ; > > Index: delete.c > --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 > +++ delete.c 11 May 2009 04:42:58 -0000 > @@ -75,4 +75,8 @@ > op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); > > + { > + struct timeval timeout = { 0, 200000 }; > + select(0, NULL, NULL, NULL,&timeout); > + } > if( op->o_req_ndn.bv_len == 0 ) { > Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", > Index: result.c > --- result.c 11 May 2009 02:23:51 -0000 1.331 > +++ result.c 11 May 2009 04:42:58 -0000 > @@ -418,4 +418,6 @@ > if (( rs->sr_err == SLAPD_ABANDON || op->o_abandon )&& !op->o_cancel ) { > rc = SLAPD_ABANDON; > + Statslog( LDAP_DEBUG_STATS, > + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); > goto clean2; > } > > -- -- 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#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 10 May '09

10 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for the canceled operation to obey o_abandon before o_cancel gets set. Though I had to insert some sleeps to achieve that. Either the operation is abandoned and the Cancel operation receives tooLate, or if the client unbinds/closes the connection fast enough Cancel will hang: slapd does not close the connection, and hangs on shutdown: "slapd shutdown: waiting for 1 operations/tasks to finish". Since the flags are not mutex-protected (at least not when read), it's not enough to move the o_cancel setting after o_abandon in the Cancel thread. The cancelled thread might still see the o_abandon change first. A fix could be to make o_abandon a bitmask which says whether the abandon is actually a cancel, but the Abandon and Cancel operations will still need a mutex to coordinate so that Abandon does not reset a Cancel bitflag. In any case, it'd be cleaner if an operation which reacts to o_abandon grabs some mutex before checking o_cancel. The problem was tested as follows: - sleep 0.2 sec after Statslog "DEL" and before setting SLAP_CANCEL_REQ. - log "ABANDONED" when send_ldap_response() abandons the operation. - Client: A python socket client which sends raw BER, no libldap: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('localhost', 3890)) s.send(delete("cn=test")) time.sleep(0.1) s.send(cancel()) # cancel last operation #sys.exit() time.sleep(0.4) s.send(unbind()) --> conn=0 fd=9 ACCEPT from IP=127.0.0.1:56945 (IP=127.0.0.1:3890) conn=0 op=0 DEL dn="cn=test" conn=0 op=1 EXT oid=1.3.6.1.1.8 conn=0 op=1 CANCEL msg=1 conn=0 op=0 ABANDONED conn=0 op=2 UNBIND conn=0 op=1 RESULT oid= err=120 text= conn=0 fd=9 closed <server closed connection, client exited> ^C slapd If the client exits after send(cancel()): conn=0 fd=9 ACCEPT from IP=127.0.0.1:48826 (IP=127.0.0.1:3890) conn=0 op=0 DEL dn="cn=test" conn=0 op=1 EXT oid=1.3.6.1.1.8 conn=0 op=1 CANCEL msg=1 conn=0 op=2 UNBIND conn=0 op=0 ABANDONED <not closing connection> ^C slapd daemon: shutdown requested and initiated. slapd shutdown: waiting for 1 operations/tasks to finish <slapd is hanging> kill -KILL <slapd> slapd.conf: include servers/slapd/schema/core.schema allow update_anon database ldif directory "." suffix "cn=test" Patches to slapd: Index: cancel.c --- cancel.c 21 Jan 2009 23:40:25 -0000 1.30 +++ cancel.c 11 May 2009 04:42:58 -0000 @@ -92,4 +92,8 @@ } + { + struct timeval timeout = { 0, 200000 }; + select(0, NULL, NULL, NULL, &timeout); + } o->o_cancel = SLAP_CANCEL_REQ; Index: delete.c --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 +++ delete.c 11 May 2009 04:42:58 -0000 @@ -75,4 +75,8 @@ op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); + { + struct timeval timeout = { 0, 200000 }; + select(0, NULL, NULL, NULL, &timeout); + } if( op->o_req_ndn.bv_len == 0 ) { Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", Index: result.c --- result.c 11 May 2009 02:23:51 -0000 1.331 +++ result.c 11 May 2009 04:42:58 -0000 @@ -418,4 +418,6 @@ if (( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) && !op->o_cancel ) { rc = SLAPD_ABANDON; + Statslog( LDAP_DEBUG_STATS, + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); goto clean2; }

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by hyc＠symas.com 10 May '09

10 May '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: linux > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > I've had two cases where a delete operation was performed on the master without > being replicated to its consumers, which so far appear to be cases of possible > connection lost (abandon) race conditions. The log (level: stats) shows the > "DEL" message of the entry, immediately followed by a "closed (connection lost)" > message on the connection. Note: No "RESULT" message was logged. > > I haven't looked very much into this, but my theory so far is that syncprov > skipped replicating of the delete op after noticing the abandon resulting from > loosing the connection, even though the delete had already taken place in the > local database. That it happened after a delete op might very well have been a > coincident, this possible race could exist after any modify op for all I know. > Do we need some sort of o_committed flag that can be used to prevent o_abandon > from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with > multiple values, including "too late"? No. What good can that do, since the connection has already been lost? It doesn't matter if syncprov fails to send an update to a consumer - the consumer's cookie state will let it pick up where it left off when it reconnects. -- -- 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#6103) canceled operations do not respond
by hyc＠symas.com 10 May '09

10 May '09

Hallvard B Furuseth wrote: > Howard Chu writes: >> The tooLate reply is correct; back-null doesn't ever check for >> cancel/abandon therefore the operation is *not* successfully >> canceled. Likewise, back-bdb/hdb only checks in Delete if there is a >> transaction retry. > > No difference if I use back-ldif, which does check for abandon. > >> The lack of reply from the original op - that's a simple oversight. >> send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I >> guess we need to also check for o_cancel to let it proceed. > > The operation does not reach send_ldap_ber(). To verify, I temporarily > inserted assert(!op->o_abandon) just before send_ldap_ber()'s o_abandon > test. send_ldap_response() notices both o_abandon and SLAPD_ABANDON, > and skips to the cleanup code in either case. > > Also, backend operations that do return SLAPD_ABANDON - at least Search > in backglue and BDB - may do so without calling send_ldap_response() at > all. Pierangelo made partial fixes in ITS#4645. See also ITS#6059, > which I may have misunderstood somewhat. (Sorry, Rein.) > > Maybe o_abandon should only mean that: > - (a) the backend has been asked to abandon the operation, > - (b) slapd must check and react to o_cancel, > - (c) if not o_cancel, send_ldap_ber() need not send. > The test case with delete / back-ldif now works in HEAD. backglue and back-bdb should be OK now as well. -- -- 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#6099) SIGSEGV heimdal+ldap during kadmin -l init
by dewayne.geraghty＠heuristicsystems.com.au 10 May '09

10 May '09

This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C9D21A.C8D0F590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Heimdal 1.0.1 was constructed from the FreeBSD 7.2R's port handling system for contributed software. From Howard's analysis, Heimdal 1.0.1 is passing incorrect values to LDAP 2.4.16. Over to heimdal's maintainer on FreeBSD. Thank-you for your prompt analysis. ------=_NextPart_000_0015_01C9D21A.C8D0F590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D407062323-10052009>Heimdal 1.0.1 was=20 constructed from the FreeBSD 7.2R's port handling system for = contributed=20 software. From Howard's analysis, Heimdal 1.0.1 is=20 passing incorrect values to LDAP 2.4.16.  Over to = heimdal's=20 maintainer on FreeBSD.  Thank-you for your prompt=20 analysis. </SPAN></FONT></DIV></BODY></HTML> ------=_NextPart_000_0015_01C9D21A.C8D0F590--

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 10 May '09

10 May '09

Howard Chu writes: > The tooLate reply is correct; back-null doesn't ever check for > cancel/abandon therefore the operation is *not* successfully > canceled. Likewise, back-bdb/hdb only checks in Delete if there is a > transaction retry. No difference if I use back-ldif, which does check for abandon. > The lack of reply from the original op - that's a simple oversight. > send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I > guess we need to also check for o_cancel to let it proceed. The operation does not reach send_ldap_ber(). To verify, I temporarily inserted assert(!op->o_abandon) just before send_ldap_ber()'s o_abandon test. send_ldap_response() notices both o_abandon and SLAPD_ABANDON, and skips to the cleanup code in either case. Also, backend operations that do return SLAPD_ABANDON - at least Search in backglue and BDB - may do so without calling send_ldap_response() at all. Pierangelo made partial fixes in ITS#4645. See also ITS#6059, which I may have misunderstood somewhat. (Sorry, Rein.) Maybe o_abandon should only mean that: - (a) the backend has been asked to abandon the operation, - (b) slapd must check and react to o_cancel, - (c) if not o_cancel, send_ldap_ber() need not send. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 10 May '09

10 May '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 3909 says both the Cancel operation and the canceled operation > shall respond. However I'm getting tooLate reply from Cancel > and no response from the successfully cancelled operation: The tooLate reply is correct; back-null doesn't ever check for cancel/abandon therefore the operation is *not* successfully canceled. Likewise, back-bdb/hdb only checks in Delete if there is a transaction retry. The lack of reply from the original op - that's a simple oversight. send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I guess we need to also check for o_cancel to let it proceed. > > slapd.conf: > include servers/slapd/schema/core.schema > database null > suffix "cn=null" > client: > DEL cn=null > sleep 0.1 sec > CANCEL<previous op> > sleep 0.2 sec > UNBIND > receives the folllowing statslog: > conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) > conn=1 op=0 DEL dn="cn=null" > conn=1 op=1 EXT oid=1.3.6.1.1.8 > conn=1 op=1 CANCEL msg=1 > conn=1 op=0 ABANDONED > conn=1 op=1 RESULT oid= err=120 text= > conn=1 op=2 UNBIND > conn=1 fd=9 closed > and the client gets just ExtendedResponse tooLate before connection closes > > with the following patch to slapd: > > Index: delete.c > --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 > +++ delete.c 9 May 2009 22:06:07 -0000 > @@ -75,4 +75,9 @@ > op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); > > + { > + struct timeval timeout = { 0, 200000 }; > + select(0, NULL, NULL, NULL,&timeout); > + } > + > if( op->o_req_ndn.bv_len == 0 ) { > Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", > Index: result.c > --- result.c 14 Mar 2009 05:47:43 -0000 1.329 > +++ result.c 9 May 2009 22:06:07 -0000 > @@ -418,4 +418,6 @@ > if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { > rc = SLAPD_ABANDON; > + Statslog( LDAP_DEBUG_STATS, > + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); > goto clean2; > } > > > -- -- 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#6102) configure skips winsock check
by hyc＠symas.com 10 May '09

10 May '09

slapd(a)hannebauer.name wrote: > Full_Name: Christoph Hannebauer > Version: 2.4.16 > OS: Windows/cygwin > URL: www.hannebauer.name/configure.in.patch > Submission from: (NULL) (77.189.243.40) > > > I use cygwin to build OpenLDAP with the MinGW target. The configure script > incorrectly skips the check for winsock. This results in a missing -lws2_32 > parameter in some makefiles, I get error messages like > > /cygdrive/d/TestProgs/openldap-2.4.16/libraries/liblber/io.c:531: undefined > reference to `_WSASetLastError@4' > > The author of ITS#6078 (http://www.openldap.org/its/index.cgi/Incoming?id=6078) > notes that this problem occurs since 2.4.14, but I haven't tested that. Thanks. Yes, the configure script handling of winsock changed between 2.4.13 and 2.4.14. This patch is now committed to HEAD. > > The attached patch file is a diff to configure.in version 1.696. I have tested > it on my machine and it solved the problem (The reason was an erroneous > if-statement. The if-condition should only evaluate true if MS Visual C++ is > used). I've also included another small fix for the winsock detection which > happened to not affect my system, but seemed obviously wrong. It's only a very > minor fix, so I assumed it would be okay to not open another ticket for that > patch. If I am wrong, please notify me and I will split up the patch file. > > I hope it's okay to have the legal statement here, otherwise I will include it > as a comment in the patch file: > I, Christoph Hannebauer, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > -- -- 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#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 09 May '09

09 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 3909 says both the Cancel operation and the canceled operation shall respond. However I'm getting tooLate reply from Cancel and no response from the successfully cancelled operation: slapd.conf: include servers/slapd/schema/core.schema database null suffix "cn=null" client: DEL cn=null sleep 0.1 sec CANCEL <previous op> sleep 0.2 sec UNBIND receives the folllowing statslog: conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) conn=1 op=0 DEL dn="cn=null" conn=1 op=1 EXT oid=1.3.6.1.1.8 conn=1 op=1 CANCEL msg=1 conn=1 op=0 ABANDONED conn=1 op=1 RESULT oid= err=120 text= conn=1 op=2 UNBIND conn=1 fd=9 closed and the client gets just ExtendedResponse tooLate before connection closes with the following patch to slapd: Index: delete.c --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 +++ delete.c 9 May 2009 22:06:07 -0000 @@ -75,4 +75,9 @@ op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); + { + struct timeval timeout = { 0, 200000 }; + select(0, NULL, NULL, NULL, &timeout); + } + if( op->o_req_ndn.bv_len == 0 ) { Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", Index: result.c --- result.c 14 Mar 2009 05:47:43 -0000 1.329 +++ result.c 9 May 2009 22:06:07 -0000 @@ -418,4 +418,6 @@ if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { rc = SLAPD_ABANDON; + Statslog( LDAP_DEBUG_STATS, + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); goto clean2; }

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