openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Fixed in HEAD, please test. BTW, the bug showed up essentially because the output was sort of incorrectly diverted to the file that gets checked. Generally speaking, it might impact re23 as well, although that test is currently succeeding. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael.stroeder(a)t-systems.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: opensuse Linux 10.2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.124.17.145) >> Hmm, all tests are passing for me right now. >> > Never mind. I just refreshed back-ldap and back-meta and test032 is failing > for me now too. I've recently added some diagnostics messages to proxy failures, to indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts to contact the remote target. Apparently, slapo-chain(5) leaves 'round some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

Howard Chu wrote: > michael.stroeder(a)t-systems.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: opensuse Linux 10.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.124.17.145) > > Hmm, all tests are passing for me right now. > Never mind. I just refreshed back-ldap and back-meta and test032 is failing for me now too. -- -- Howard Chu Chief Architect, 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

michael.stroeder(a)t-systems.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: opensuse Linux 10.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.17.145) Hmm, all tests are passing for me right now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by michael.stroeder＠t-systems.com 01 Feb '07

01 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: opensuse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.145) >>>>> Starting test032-chain ... running defines.sh Running slapadd to build slapd database... Starting first slapd on TCP/IP port 9011... Starting second slapd on TCP/IP port 9012... Using ldapsearch to check that first slapd is running... Using ldapsearch to check that second slapd is running... Testing ldapsearch as anonymous for "dc=example,dc=com" on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Reading the referral entry ou=Other,dc=example,dc=com as anonymous on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - chained search didn't succeed >>>>> ./scripts/test032-chain failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 31 Jan '07

31 Jan '07

On Feb 1, 2007, at 4:26 AM, hyc(a)symas.com wrote: > Fixed now. Confirmed. Thanks, Kurt

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by hyc＠symas.com 31 Jan '07

31 Jan '07

Fixed now. The fix also triggered another problem along the lines of ITS#4820; test017's comparison failed because the modifiersName attribute wasn't in the same position on the producer and the consumer. I've hacked that problem by always applying the modifiersName update. kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacOSX 10.4.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.80.218.136) > > > Recent builds fail test 18: > Comparing retrieved entries from master and R1 slave... > Comparing retrieved entries from master and R2 slave... > test failed - master and R2 slave databases differ >>>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) > > % diff -u testrun/server[13].flt > --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 > +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 > @@ -66,6 +66,7 @@ > seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com > userPassword:: Ympvcm4= > homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 > +drink: Iced Tea > description: Hiker, biker > title: Director, Embedded Systems > postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 > @@ -74,8 +75,6 @@ > pager: +1 313 555 4474 > facsimileTelephoneNumber: +1 313 555 2177 > telephoneNumber: +1 313 555 0355 > -drink: Iced Tea > -drink: Mad Dog 20/20 > > dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com > objectClass: OpenLDAPperson > > > . > -- -- Howard Chu Chief Architect, 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#4826) assertion in connection.c
by ando＠sys-net.it 31 Jan '07

31 Jan '07

hyc(a)symas.com wrote: > Aaron Richton wrote: >> Wow, thanks. I never worried about setting that because I was under the >> impression that Solaris should autoconf to use poll() -- doesn't >> FD_SETSIZE only matter under select()? > > In current releases slapd only uses select() or epoll() (which is > Linux-specific). So you're getting select() right now. In HEAD/2.4 there's > support for Solaris /dev/poll. ... which doesn't work right now (as far as I remember; need to look at that before Solaris 8 becomes obsolete...) p.

1 0

Re: (ITS#4826) assertion in connection.c
by hyc＠symas.com 31 Jan '07

31 Jan '07

Aaron Richton wrote: > Wow, thanks. I never worried about setting that because I was under the > impression that Solaris should autoconf to use poll() -- doesn't > FD_SETSIZE only matter under select()? In current releases slapd only uses select() or epoll() (which is Linux-specific). So you're getting select() right now. In HEAD/2.4 there's support for Solaris /dev/poll. The libldap library will use poll() on Solaris, but that's a different matter... > On Wed, 31 Jan 2007, Howard Chu wrote: > >> richton(a)nbcs.rutgers.edu wrote: >>> Full_Name: Aaron Richton >>> Version: 2.3.30 >>> OS: Solaris 9 >>> URL: Submission from: (NULL) (128.6.31.135) -- -- Howard Chu Chief Architect, 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#4826) assertion in connection.c
by richton＠nbcs.rutgers.edu 31 Jan '07

31 Jan '07

Wow, thanks. I never worried about setting that because I was under the impression that Solaris should autoconf to use poll() -- doesn't FD_SETSIZE only matter under select()? On Wed, 31 Jan 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: 2.3.30 >> OS: Solaris 9 >> URL: Submission from: (NULL) (128.6.31.135) >> >> >> Please note this is 2.3.30, so recent RE23 connection changes might make >> this >> irrelevant: > > No, no recent changes to connection.c would affect this. If your process is > actually able to use more than 4096 connections, then you need to recompile > with a larger OPENLDAP_FD_SET_SIZE. > > Note that with dtblsize = 4096, the maximum legal descriptor number is 4095, > since descriptors are zero-based. > > I'd call this a user configuration error, nothing to investigate here. > > -- > -- Howard Chu > Chief Architect, 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