- openldap-bugs - openldap.org

Re: (ITS#7112) Slapd Daemon leaking file descriptor
by quanah＠zimbra.com 16 Dec '11

16 Dec '11

--On Friday, December 16, 2011 5:45 AM +0000 aditya1606(a)gmail.com wrote: > Full_Name: Aditya Bajaj > Version: 2.2.30 > OS: RHEL 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.100.112.203) 2.2 is not a supported release series. 2.3 is not a supported release series. Upgrade to a supported release series. This ticket will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7112) Slapd Daemon leaking file descriptor
by aditya1606＠gmail.com 16 Dec '11

16 Dec '11

Full_Name: Aditya Bajaj Version: 2.2.30 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.100.112.203) Hello, losf of slapd is showing like this slapd 10127 root 585u sock 0,5 3532897126 can't identify protocol we have read openldap previous queries , were it as being mentioned that its already fixed in 2.3.32 or after. My question is what was the ticket number that fixed this issue. we would like to now more about that ticket. Regards Aditya

1 0

(ITS#7111) Forward bug-fix commits to ITS
by hyc＠OpenLDAP.org 16 Dec '11

16 Dec '11

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Testing...

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 16 Dec '11

16 Dec '11

hume-ol(a)bofh.ca wrote: > I have reproduced the problem on 2.4.27. The mentioned ldapsearch query > seems to have a high probability of success if run immediately after > server start, which also seems true on 2.4.28. > > I threw in an extra Debug() line and op->op_protocol == 2 at the check. > > I'm rebuilding with as many debugging symbols enabled as possible to try > to figure out what's going on. A fix for this is in git master, 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

(ITS#7110) cn=config mixes values
by raphael.ouazana＠linagora.com 15 Dec '11

15 Dec '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, I try to modify valuse of eg. olcAccess with a certain order, I get different values if numbered values are in the correct order or not. Case 1 (normal): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write Case 2 (inversed values): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write The two last values are incorrectly mixed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 14 Dec '11

14 Dec '11

I wrote: >> And what information should we provide to solve this problem? (strace, gdb >> log, db_stat or something else?) > > Server log from slapd, and gdb 'thread apply all backtrace'. Eh, I forgot the obvious one: slapd's configuration, minus any passwords. -- Hallvard

1 0

Re: (ITS#7109) Slapd Freezing
by quanah＠zimbra.com 12 Dec '11

12 Dec '11

--On Saturday, December 10, 2011 7:07 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Unfortunately OpenLDAP installation strips debugging symbols by default, > which makes backtraces nearly useless. You can prevent that by > configuring with > ./configure --enable-memberof ac_cv_prog_STRIP=: You can also do it at install time by simply typing: make install STRIP="" --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7050) meta stop at the first unreachable candidate
by hyc＠symas.com 12 Dec '11

12 Dec '11

llg(a)portaildulibre.fr wrote: > Does anybody knows if and when this patch will be included in future > versions ? No, the patch is wrong. A new fix is in git master now. -- -- 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#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 10 Dec '11

10 Dec '11

nikolay.bogdanov(a)flant.ru writes: > Version: 2.4.23 > (...) What can you advice for us? Upgrade, building from the source at www.openldap.org. There are several possibly-related bugfixes since 2.4.23. Then report back whether nor not that fixed the problem. If it is: > And what information should we provide to solve this problem? (strace, gdb > log, db_stat or something else?) Server log from slapd, and gdb 'thread apply all backtrace'. Unfortunately OpenLDAP installation strips debugging symbols by default, which makes backtraces nearly useless. You can prevent that by configuring with ./configure --enable-memberof ac_cv_prog_STRIP=: -- Hallvard

1 0

(ITS#7109) Slapd Freezing
by nikolay.bogdanov＠flant.ru 10 Dec '11

10 Dec '11

Full_Name: Nikolay Bogdanov Version: 2.4.23 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/sysinfo.txt Submission from: (NULL) (95.221.182.198) Dear ñolleagues, We used open ldap for three years. But some weeks ago we disided to restructurate our LDAP server. We did it, but there are a lot of users in the company. So we enabled the "rwm" overlay and added "oldDn" field in a schema. Futhermore, we use "memberof" overlay. As a result users can bind with their old dn. But after that slapd stops with deadlock everyday. What can you advice for us? And what information should we provide to solve this problem? (strace, gdb log, db_stat or something else?) With best regards, Nikolay Bogdanov. CJSC Flant.

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 09 Dec '11

09 Dec '11

I have reproduced the problem on 2.4.27. The mentioned ldapsearch query seems to have a high probability of success if run immediately after server start, which also seems true on 2.4.28. I threw in an extra Debug() line and op->op_protocol == 2 at the check. I'm rebuilding with as many debugging symbols enabled as possible to try to figure out what's going on.

1 0

Re: (ITS#7050) meta stop at the first unreachable candidate
by llg＠portaildulibre.fr 09 Dec '11

09 Dec '11

Does anybody knows if and when this patch will be included in future versions ? Thanks llg

1 0

Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by hyc＠symas.com 08 Dec '11

08 Dec '11

mkrz(a)free.fr wrote: > Full_Name: Martin Krzaczek > Version: 2.4.28 > OS: CentOS 5.7 > URL: > Submission from: (NULL) (83.202.204.201) > > > Hello, > > I noticed an issue with "refreshOnly" syncrepl when a large number of records is > added, updated and deleted. At the end of synchronization the contextCSN is > equal on all servers, but the data is out of synchronization for some deleted > records that remains undeleted on consumer/slave servers. > > Restarting the consumer or forcing a synchronization with "slapd ... -c > 'rid=1,csn=0' " does not help. This appears to caused by the sessionlog overflowing due to incoming modifies that occur after the refresh operation has begun. I would call this a misconfigured server, since the sessionlog can only ever be useful if you size it large enough to accomodate all of your update traffic. I don't have any plans to fix this issue; fix the server configuration. > > A similar issue was submitted few weeks ago (ITS#7052), but I'm not sure the > problem is the same. > > My configuration : > - CentOS 5.7 + OpenLDAP 2.4.28 + BDB 5.1.29 > (the same issue occurs with CentOS 5.7 + OpenLDAP 2.4.26 + BDB 5.1.25) > - one main provider where all modification operations are performed > - one 'first level' consumer synchronizing data on the main provider > and providing data for 'second level' consumers > - one 'second level' consumer synchronizing data on the 'first level' > consumer/provider > > I tried several combinations of configurations (refreshOnly/refreshAndPersist, > syncprov-sessionlog) and noticed that when refreshOnly mode is used, some > records may be not deleted on consumer/slave servers. The number of undeleted > records varies depending on the configuration. > So with a higher value of "syncprov-sessionlog" (for example 5000 instead of > 500) the number of lost records is reduced. > > I have an application that sequentially (i.e. in a single thread) adds about > 12000 records, modifies about 25000 records and deletes about 1000 records. > Add/update/delete operations are mixed i.e. it is possible a have sequences such > as add/add/delete/update/update/update/delete/add/... > > With a small amount of records to add/update/delete the synchronization properly > works without any data loss. > So it seams that if all modifications may be cached and transmitted to consumers > then deleted records are not lost. > There is no data loss for added and updated records whatever is the number of > operations. > > > Regards, > Martin > > > -- -- 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#7108) syncrepl loses updates when replica is down
by hyc＠symas.com 08 Dec '11

08 Dec '11

ml+openldap(a)esmtp.org wrote: > Full_Name: Claus Assmann > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch > Submission from: (NULL) (63.211.143.38) > > > This is a followup to ITS 7037 which has been fixed in 2.4.28. > It is the same setup and test -- I've uploaded a "patch" that > includes the test program (sorry if it doesn't follow all > the OpenLDAP conventions, I hope it is sufficient to reproduce > the problem). > > It looks like some changes to the OpenLDAP master are not transferred to the > replica (the test prg demonstrates that). > > Note: in my test runs it doesn't always fail, but almost all the time. > > Please let me know whether my test is broken or whether there is a problem in > slapd. I would consider this test invalid. You're deleting the replica database while the consumer is still running. The slapd consumer code assumes that it is the only thing that can make changes to a consumer database. -- -- 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#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 08 Dec '11

08 Dec '11

hume-ol(a)bofh.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.28 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.28 compiled with BerkeleyDB 5.2.36, attempting to configure for > multi-master replication. Problems occurred with the second server complaining > about operations errors while attempting to replicate the cn=config tree; I've > been able to reproduce the problem from the command line using ldapsearch from > the same compile. > > The host is RHEL 6.1 running inside VMWare. Version of OpenLDAP is 2.4.28, > compiled with BerkeleyDB 5.2.36 (no patches available from Oracle at the time I > downloaded). Configuration options used are visible in > http://den.bofh.ca/~hume/config_ol_sh.txt > > The problem does *not* seem to be consistent, as *sometimes* it will work but > most of the time not. I've run the example query once, had it fail, run it > again immediately and had it succeed, and then again fail a dozen times in a > row. Wireshark traces showed the connection was established using LDAPv3; > putting the server in debug "Any" mode also confirms the same. The syslogs > generated are viewable at http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > > I've compiled 2.4.27 with the same options and it *seemed* to behave, though I > may have merely gotten lucky. Only two source files are changed between 2.4.27 and 2.4.28, and neither of the changes affect cn=config, syncrepl, or Bind operations. If you're seeing a difference in behavior here then I can only conclude that your build environment is corrupted. > Example ldapsearch invocation: > > $ /appl/ldap/bin/ldapsearch -x -D 'cn=config' -h kil-ds-3.its.dal.ca -b > cn=config -w bindpass -s sub -E sync=rp -e manageDSAit 'objectclass=*' > # extended LDIF > # > # LDAPv3 > # base<cn=config> with scope subtree > # filter: objectclass=* > # requesting: ALL > # with manageDSAit control > # > > # search result > search: 2 > result: 2 Protocol error > text: controls require LDAPv3 > > # numResponses: 1 > ldap_result: Can't contact LDAP server (-1) > > > These servers are not yet in production and I have ~two weeks to play and tweak > to generate more debugging information if you'd find it useful. > > -- -- 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#7108) syncrepl loses updates when replica is down
by ml+openldap＠esmtp.org 08 Dec '11

08 Dec '11

Full_Name: Claus Assmann Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.3 URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch Submission from: (NULL) (63.211.143.38) This is a followup to ITS 7037 which has been fixed in 2.4.28. It is the same setup and test -- I've uploaded a "patch" that includes the test program (sorry if it doesn't follow all the OpenLDAP conventions, I hope it is sufficient to reproduce the problem). It looks like some changes to the OpenLDAP master are not transferred to the replica (the test prg demonstrates that). Note: in my test runs it doesn't always fail, but almost all the time. Please let me know whether my test is broken or whether there is a problem in slapd. this is the failure output from running ./run syncrepl-ldap in the tests/ directory: test failed - master and slave databases differ 79,83d78 < dn: dc=com < dc: com < objectClass: top < objectClass: domain < 101,115d95 < dn: dc=example,dc=com < dc: example < objectClass: organization < objectClass: domainRelatedObject < objectClass: dcObject < l: Anytown, Michigan < st: Michigan < o: Example, Inc. < o: EX < o: Ex. < description: The Example, Inc. at Anytown < postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US < telephoneNumber: +1 313 555 1817 < associatedDomain: example.com

1 0

(ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 08 Dec '11

08 Dec '11

Full_Name: Brandon Hume Version: 2.4.28 OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 URL: http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) OpenLDAP 2.4.28 compiled with BerkeleyDB 5.2.36, attempting to configure for multi-master replication. Problems occurred with the second server complaining about operations errors while attempting to replicate the cn=config tree; I've been able to reproduce the problem from the command line using ldapsearch from the same compile. The host is RHEL 6.1 running inside VMWare. Version of OpenLDAP is 2.4.28, compiled with BerkeleyDB 5.2.36 (no patches available from Oracle at the time I downloaded). Configuration options used are visible in http://den.bofh.ca/~hume/config_ol_sh.txt The problem does *not* seem to be consistent, as *sometimes* it will work but most of the time not. I've run the example query once, had it fail, run it again immediately and had it succeed, and then again fail a dozen times in a row. Wireshark traces showed the connection was established using LDAPv3; putting the server in debug "Any" mode also confirms the same. The syslogs generated are viewable at http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt I've compiled 2.4.27 with the same options and it *seemed* to behave, though I may have merely gotten lucky. Example ldapsearch invocation: $ /appl/ldap/bin/ldapsearch -x -D 'cn=config' -h kil-ds-3.its.dal.ca -b cn=config -w bindpass -s sub -E sync=rp -e manageDSAit 'objectclass=*' # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: objectclass=* # requesting: ALL # with manageDSAit control # # search result search: 2 result: 2 Protocol error text: controls require LDAPv3 # numResponses: 1 ldap_result: Can't contact LDAP server (-1) These servers are not yet in production and I have ~two weeks to play and tweak to generate more debugging information if you'd find it useful.

1 0

Re: (ITS#7106) NSS and NSPR on Oracle Linux
by hyc＠symas.com 06 Dec '11

06 Dec '11

openldap(a)myname.nl wrote: > Full_Name: Daniël van Eeden > Version: 2.4.28 > OS: Oracle Linux 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:610:62d:0:5a94:6bff:fe5e:6904) > > > When doing a configure on Oracle linux 6.1 (extremely similair to RHEL 6.1) it > reports that nssutil.h > > checking nssutil.h usability... no > checking nssutil.h presence... no > checking for nssutil.h... no > configure: error: MozNSS not found - please specify the location to the NSPR and > NSS header files in CPPFLAGS and the location to the NSPR and NSS libraries in > LDFLAGS (if not in the system location) > > I've installed nspr4 and nss3 using the official oracle packages, so I shouldn't > need to set CPPFLAGS as the header files are installed in the system location. > > With these CPP flags it does work: > export CPPFLAGS="-I/usr/include/nss3 -I/usr/include/nspr4" > > I believe that OpenLDAP's configure should be able to locate these files as long > as they're installed in the official locations from the official media. There is no "official" location for NSS or NSPR header files, it varies with every system. This ITS will be closed. -- -- 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#7106) NSS and NSPR on Oracle Linux
by openldap＠myname.nl 06 Dec '11

06 Dec '11

Full_Name: Daniël van Eeden Version: 2.4.28 OS: Oracle Linux 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:610:62d:0:5a94:6bff:fe5e:6904) When doing a configure on Oracle linux 6.1 (extremely similair to RHEL 6.1) it reports that nssutil.h checking nssutil.h usability... no checking nssutil.h presence... no checking for nssutil.h... no configure: error: MozNSS not found - please specify the location to the NSPR and NSS header files in CPPFLAGS and the location to the NSPR and NSS libraries in LDFLAGS (if not in the system location) I've installed nspr4 and nss3 using the official oracle packages, so I shouldn't need to set CPPFLAGS as the header files are installed in the system location. With these CPP flags it does work: export CPPFLAGS="-I/usr/include/nss3 -I/usr/include/nspr4" I believe that OpenLDAP's configure should be able to locate these files as long as they're installed in the official locations from the official media.

1 0

(ITS#7105) Feature Request: accesslog exclude rule
by marco.pizzoli＠gmail.com 05 Dec '11

05 Dec '11

Full_Name: Marco Pizzoli Version: ALL OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) Hi, This is a feature request. I would like to take forward what started with ITS#6815. My request is to extend slapo-accesslog flexibility by introducing a directive "logbase-exclude". My request is to exclude a particular basedn to be logged by slapo-accesslog. If I have a tree with several ou's at the same level, it seems to me a lot inefficient to explicit all ou's logbases except one, only to exclude one of them. Thanks in advance Marco

1 0

(ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by mkrz＠free.fr 04 Dec '11

04 Dec '11

Full_Name: Martin Krzaczek Version: 2.4.28 OS: CentOS 5.7 URL: Submission from: (NULL) (83.202.204.201) Hello, I noticed an issue with "refreshOnly" syncrepl when a large number of records is added, updated and deleted. At the end of synchronization the contextCSN is equal on all servers, but the data is out of synchronization for some deleted records that remains undeleted on consumer/slave servers. Restarting the consumer or forcing a synchronization with "slapd ... -c 'rid=1,csn=0' " does not help. A similar issue was submitted few weeks ago (ITS#7052), but I'm not sure the problem is the same. My configuration : - CentOS 5.7 + OpenLDAP 2.4.28 + BDB 5.1.29 (the same issue occurs with CentOS 5.7 + OpenLDAP 2.4.26 + BDB 5.1.25) - one main provider where all modification operations are performed - one 'first level' consumer synchronizing data on the main provider and providing data for 'second level' consumers - one 'second level' consumer synchronizing data on the 'first level' consumer/provider I tried several combinations of configurations (refreshOnly/refreshAndPersist, syncprov-sessionlog) and noticed that when refreshOnly mode is used, some records may be not deleted on consumer/slave servers. The number of undeleted records varies depending on the configuration. So with a higher value of "syncprov-sessionlog" (for example 5000 instead of 500) the number of lost records is reduced. I have an application that sequentially (i.e. in a single thread) adds about 12000 records, modifies about 25000 records and deletes about 1000 records. Add/update/delete operations are mixed i.e. it is possible a have sequences such as add/add/delete/update/update/update/delete/add/... With a small amount of records to add/update/delete the synchronization properly works without any data loss. So it seams that if all modifications may be cached and transmitted to consumers then deleted records are not lost. There is no data loss for added and updated records whatever is the number of operations. Regards, Martin

1 0

Re: (ITS#7085) mutex lockup issue
by quanah＠zimbra.com 02 Dec '11

02 Dec '11

--On Friday, December 02, 2011 11:41 AM -0500 Soichi Hayashi <hayashis(a)indiana.edu> wrote: > Quanah, > > > Were you able to recreate this issue? > Hi Soichi, I have not even attempted to reproduce it. I will see if I have time in my lab to do so. However, I use BDB 5.2.28. I will note that the backtrace you provided is useless, since you apparently did not build your binaries with debugging symbols, which is always advised. I also don't know what optimization level you used, but I strongly advise against building optimized OpenLDAP builds, gcc rarely does the right thing. Finally, OpenLDAP doesn't use select() on Linux platforms, it uses poll() which appears to be what you're backtrace indicates as well. Since you don't have debugging symbols enabled, it's virtually impossible to determine where the problem is originating. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7085) mutex lockup issue
by hayashis＠indiana.edu 02 Dec '11

02 Dec '11

--0016364c7ac7fff89504b31ea350 Content-Type: text/plain; charset=ISO-8859-1 Quanah, Were you able to recreate this issue? Soichi On Wed, Nov 16, 2011 at 3:56 PM, Soichi Hayashi <hayashis(a)indiana.edu>wrote: > Quanah, > > We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 > hours into our testing in similar manner to what I have reported earlier. I > believe this issue still occurs on the latest version. > > However, when I used gdb, I didn't notice the mutex locked threads like I > did with OpenLDAP 2.4.22. > > Following is from locked 2.4.26 slapd server. > > (gdb) info thread > 14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait () > from /lib64/libc.so.6 > 13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from > /lib64/libc.so.6 > 2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > * 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join > () from /lib64/libpthread.so.0 > (gdb) thread 3 > [Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0 > 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > #1 0x000000000054ece5 in ?? () > #2 0x000000000054aa15 in ?? () > #3 0x0000000000557637 in ?? () > #4 0x0000000000557c11 in ?? () > #5 0x00000000004b2d93 in ?? () > #6 0x00000000004e9d7c in ?? () > #7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0 > #8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6 > > It looks like it's waiting on select() on thread 3 which never get fired > when I access it using ldapsearch command. > > I ran strace on ldapsearch (on a client machine) and following is what I > see at the end of the log.. > > $ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b > mds-vo-name=WT2,o=grid > "(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))" > > .... > write(1, "\n", 1 > ) = 1 > write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110 > poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1 > > Not sure if this strace is useful or not.. but after this, ldapsearch > never returned. > > Thanks, > Soichi > > > On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > >> --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote: >> >> Full_Name: Soichi Hayashi >>> Version: 2.4.22 >>> >> >> OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a >> current release (2.4.26). This report will not be investigated unless you >> can reproduce it with a current release of OpenLDAP. You also fail to note >> what BDB release you are using, and whether or not it has all the relevant >> patches applied to it. If you have a broken policy of only using vendor >> provided packages, then you will need to send a bug report to RedHat, as it >> is their job to maintain their vendor packages. >> >> >> Thanks! >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > > --0016364c7ac7fff89504b31ea350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quanah,<div><br></div><div>Were you able to recreate this issue?</div><div>= <br></div><div>Soichi<br><div><br><div class=3D"gmail_quote">On Wed, Nov 16= , 2011 at 3:56 PM, Soichi Hayashi <span dir=3D"ltr"><<a href=3D"mailto:h= ayashis(a)indiana.edu">hayashis(a)indiana.edu</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div>Quanah,</div><div><br></div><div>We ha= ve compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 hours= into our testing in similar manner to what I have reported earlier. I beli= eve this issue still occurs on the latest version.</div> <div><br></div><div>However, when I used gdb, I didn't notice the mutex= locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F= ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div> (gdb) info thread</div> <div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa= it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) = =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp= thread.so.0</div> <div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre= ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC= _2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa= d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_= 2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread= 0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread= 0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread = 0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s= o.6</div> <div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x= 2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib= 64/libpthread.so.0</div> <div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW= P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><= div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li= bc.so.6</div> <div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i= n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000= 00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>= #6 =A00x00000000004e9d7c in ?? ()</div> <div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.= 0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div= ><div><br></div><div>It looks like it's waiting on select() on thread 3= which never get fired when I access it using ldapsearch command.=A0</div> <div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo= llowing is what I see at the end of the log..</div><div><br></div><div>$ st= race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg= rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))= "</div> <div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "= 0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di= v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div> <div><br></div><div>Not sure if this strace is useful or not.. but after th= is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S= oichi</div><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div><br><div = class=3D"gmail_quote"> On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<= a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah(a)zimbra.com</a>= ></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Wednesday, November 09, 2011 2:01 PM +0= 000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@indi= ana.edu</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Soichi Hayashi<br> Version: 2.4.22<br> </blockquote> <br> OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a= current release (2.4.26). =A0This report will not be investigated unless y= ou can reproduce it with a current release of OpenLDAP. =A0You also fail to= note what BDB release you are using, and whether or not it has all the rel= evant patches applied to it. =A0If you have a broken policy of only using v= endor provided packages, then you will need to send a bug report to RedHat,= as it is their job to maintain their vendor packages.<br> <br> <br> Thanks!<span><font color=3D"#888888"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></span></blockquote></div><br> </div></div></blockquote></div><br></div></div> --0016364c7ac7fff89504b31ea350--

1 0

Re: (ITS#6962) Download down?
by h.b.furuseth＠usit.uio.no 30 Nov '11

30 Nov '11

h.b.furuseth(a)usit.uio.no writes: >demian.djrn(a)gmail.com writes: >> all mirrors are down, i can't download the program. > > The mirror list needs to be updated. These are down or obsolete: > > Costa Rica: No /openldap directory. Still missing in the directory listing at <http://mirrors.ucr.ac.cr/>. > Italy: Unknown host it.openldap.org. > Korea: No route to host ftp.holywar.net; TTL exceeded. > Portugal: Last update was in 2008. I notice these have been removed from the mirror list now. -- Hallvard

1 0

(ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by dieter＠dkluenter.de 30 Nov '11

30 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs