openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 19 Nov '11

19 Nov '11

Full_Name: Mark A. Ziesemer Version: 2.4.2 OS: Ubuntu Linux 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.156.254.191) Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is listed as a confirmed issue for Ubuntu at https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at least 12 users - and there is no evidence to show that this is an issue specific to Ubuntu. Please also refer to and at least acknowledge the unaddressed comments left in response to #6548, which includes a report from a Debian user as well. To clarify, this appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.25), and not the slapd daemon.

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 18 Nov '11

18 Nov '11

hans.moser(a)ofd-z.niedersachsen.de wrote: > Howard, > > Howard Chu schrieb (17.11.2011 23:54 Uhr): >> Marc Patermann wrote: > >>> Howard Chu schrieb (01.11.2011 18:39 Uhr): >>> >>>> Also, this script just performs sync searches, what do you use to >>>> generate the writes? >>> you mean the write which kills the server? >>> It just one simple mod of an object which I made in Apache Directory >>> Studio. >> >> I'm unable to reproduce this crash. I have your slapd.conf and test >> data, I have run 80-some instances of your script as you've described. > I ran 80 instances of each of the three script, where each script > replicates one database, so 240 instances of the script in total. OK. After starting 240 instances and performing the modify, I saw a SEGV due to syncprov. I've patched this in git master, please test. It runs OK for me now. > >> While the initial sync search is running I perform a modify of the base >> entry of the subordinate database. Everything continues to run. I've >> also waited for all of the initial refresh traffic to finish first, and >> then perform the modify, and still no crash. >> >> To be more clear - do you perform your modify while the sync searches >> are still refreshing, or after all of the refreshes have completed? > IIRC it does not make any difference, but I definitly crashed the server > while at least one database still replicated. > >> Do you run the clients on the same host as slapd, or on a remote machine? > I had slapd one one machine and the script on another one. > > > Marc > > > -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 17 Nov '11

17 Nov '11

Howard, Howard Chu schrieb (17.11.2011 23:54 Uhr): > Marc Patermann wrote: >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory >> Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test > data, I have run 80-some instances of your script as you've described. I ran 80 instances of each of the three script, where each script replicates one database, so 240 instances of the script in total. > While the initial sync search is running I perform a modify of the base > entry of the subordinate database. Everything continues to run. I've > also waited for all of the initial refresh traffic to finish first, and > then perform the modify, and still no crash. > > To be more clear - do you perform your modify while the sync searches > are still refreshing, or after all of the refreshes have completed? IIRC it does not make any difference, but I definitly crashed the server while at least one database still replicated. > Do you run the clients on the same host as slapd, or on a remote machine? I had slapd one one machine and the script on another one. Marc

1 0

Re: (ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > >>> > The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, > back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for > assertion failure, if op->o_do_not_cache flag is set and there is no valid > binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI > for the remote AD Windows box is such a case. > <<< > > So it sounds like this assert only triggers because you have an invalid > configuration. I don't believe your patch is the correct solution if that's > the only error case. I've committed an alternate fix, turning the assert into an error return. Please test. -- -- 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#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

tedcheng(a)symas.com wrote: > The following patch fixed the issue: > > Index: servers/slapd/back-ldap/bind.c > =================================================================== > RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -u -r1.12 -r1.13 > --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 > +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 > @@ -2056,7 +2056,7 @@ > struct berval ndn; > int dobind = 0; > > - if ( op->o_conn == NULL || op->o_do_not_cache ) { > + if ( op->o_conn == NULL ) { > goto done; > } > In your original post you state: >>> The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. <<< So it sounds like this assert only triggers because you have an invalid configuration. I don't believe your patch is the correct solution if that's the only error case. -- -- 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#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 17 Nov '11

17 Nov '11

The following patch fixed the issue: Index: servers/slapd/back-ldap/bind.c =================================================================== RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 @@ -2056,7 +2056,7 @@ struct berval ndn; int dobind = 0; - if ( op->o_conn == NULL || op->o_do_not_cache ) { + if ( op->o_conn == NULL ) { goto done; } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > Marc Patermann wrote: >> Howard, >> >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test data, I > have run 80-some instances of your script as you've described. While the > initial sync search is running I perform a modify of the base entry of the > subordinate database. Everything continues to run. I've also waited for all of > the initial refresh traffic to finish first, and then perform the modify, and > still no crash. > > To be more clear - do you perform your modify while the sync searches are > still refreshing, or after all of the refreshes have completed? > > Do you run the clients on the same host as slapd, or on a remote machine? By the way... Your backtrace shows a crash down a code path that only gets executed when an operation is abandoned. None of the steps you've outlined ever cause an abandon or connection close to occur, so again, we can't duplicate the problem. -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

Marc Patermann wrote: > Howard, > > Howard Chu schrieb (01.11.2011 18:39 Uhr): > >> Also, this script just performs sync searches, what do you use to >> generate the writes? > you mean the write which kills the server? > It just one simple mod of an object which I made in Apache Directory Studio. I'm unable to reproduce this crash. I have your slapd.conf and test data, I have run 80-some instances of your script as you've described. While the initial sync search is running I perform a modify of the base entry of the subordinate database. Everything continues to run. I've also waited for all of the initial refresh traffic to finish first, and then perform the modify, and still no crash. To be more clear - do you perform your modify while the sync searches are still refreshing, or after all of the refreshes have completed? Do you run the clients on the same host as slapd, or on a remote machine? -- -- 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#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 16 Nov '11

16 Nov '11

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> What git commit ID? >> >> As said in former times: Before reporting an ITS I *always* do git pull >> checking whether there was something committed after the tested build. If >> there was a new commit I always retest. > > Please just answer the questions. Bear in mind that there is a propagation > delay between the writable git-master and the public mirror. fe1659fc5b01530401174cef3f381ce56918476f Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 16 Nov '11

16 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> What git commit ID? > > As said in former times: Before reporting an ITS I *always* do git pull > checking whether there was something committed after the tested build. If > there was a new commit I always retest. Please just answer the questions. Bear in mind that there is a propagation delay between the writable git-master and the public mirror. I always have good reasons for asking for the information that I ask for. Second-guessing me is not going to get problems solved faster. -- -- 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

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