openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org 24 Sep '13

24 Sep '13

--089e0160bd36360a0704e7231e09 Content-Type: text/plain; charset=UTF-8 I have recloned the database overnight to make sure - the problem persists. Semyon On Mon, Sep 23, 2013 at 4:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > [..] > Was this database created with OpenLDAP 2.4.36 back-mdb, or did it > originate with a previous release of OpenLDAP? > --089e0160bd36360a0704e7231e09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">I have recloned the database ov= ernight to make sure - the problem persists.<br><br></div><div class=3D"gma= il_extra">Semyon<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai= l_quote"> On Mon, Sep 23, 2013 at 4:32 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:1px #ccc solid;padding-left:1ex"> [..]<br> Was this database created with OpenLDAP 2.4.36 back-mdb, or did it originat= e with a previous release of OpenLDAP?<br></blockquote></div><br></div></di= v> --089e0160bd36360a0704e7231e09--

1 0

(ITS#7708) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org 24 Sep '13

24 Sep '13

Full_Name: Semyon Chaichenets Version: 2.4.36 OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.128.11.113) We have an issue whereby a paged-search operation causes slapd to segfault. At this point, I can only reproduce the issue on our production data - for which I cannot share coredumps. I am working on isolating the issue but would appreciate any help from openLDAP developers. The issue is triggered by the following search: ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt '(uid=m*)' We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in the sense that it may or may not happen for filters matching other sets, but it can be reproduced reliably for any given filter/page size combination. On our setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126. The issue is specific to back-mdb; backtrace points to dn2id.c: #0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 #1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00) at ../../../../../servers/slapd/back-mdb/search.c:747 [..] I would greatly appreciate any help you could give me with this problem. Best, Semyon

1 0

Re: (ITS#7707) HDB very slow with _lots_ of aliases
by h.b.furuseth＠usit.uio.no 24 Sep '13

24 Sep '13

Yes. Aliases are a pain. Lots of aliases are not recommended. They defeat your indexes: When you search with alias dereferencing "always" or "search", the server must follow every alias in the search scope to see if it leads to entries which should be returned. This will not be fixed, such a change would be too invasive. -- Hallvard

1 0

Re: (ITS#7707) HDB unable to find record with _lots_ of aliases
by m.innocenti＠cineca.it 24 Sep '13

24 Sep '13

Sorry for the wrong Subject. I have tested MDB and the problem is not present but the query are way to slow to be usable. The first query took 10m30s to finish, the second one 191m31s.

1 0

(ITS#7707) HDB very slow with _lots_ of aliases
by m.innocenti＠cineca.it 24 Sep '13

24 Sep '13

Full_Name: Marco Innocenti Version: 2.4.36 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.186.19.81) Hi, I do administer a system which hosts a slapd instance (2.4.36) which is used by one of our customer which use a tree with tens of thousand of aliases. The backend is HDB. If I do a search with alias dereferencing set to always using "ou=1004,ou=studenti,o=uni,dc=uni,dc=it" as a base I do find the record I'm looking for. vm:~# time ldapsearch -x -H ldap://localhost:8501 -D 'cn=manager,dc=uni,dc=it' -W -b ou=1004,ou=studenti,o=uni,dc=uni,dc=it uid=mario.rossi -a always | grep \# Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=1004,ou=studenti,o=uni,dc=uni,dc=it> with scope subtree # filter: uid=mario.rossi # requesting: ALL # # mario.rossi, m, utenti, uni, uni.it # search result # numResponses: 2 # numEntries: 1 real 0m1.607s user 0m0.000s sys 0m0.000s If I do the same search on the parent of the previously used base ("ou=studenti,o=uni,dc=uni,dc=it" vs "ou=1004,ou=studenti,o=uni,dc=uni,dc=it") I do not get any record and no errors are logged. vm:~# time ldapsearch -x -H ldap://localhost:8501 -D cn=manager,dc=uni,dc=it -W -b ou=studenti,o=uni,dc=uni,dc=it uid=mario.rossi -a always Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=studenti,o=uni,dc=uni,dc=it> with scope subtree # filter: uid=mario.rossi # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 real 0m5.301s user 0m0.004s sys 0m0.000s

1 0

(ITS#7706) RFE: contrib/slapo-lastbind extension
by marco.pizzoli＠gmail.com 24 Sep '13

24 Sep '13

Full_Name: Marco Pizzoli Version: until 2.4.36 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) This is another RFE for slapo-lastbind I would appreciate being able to prevent some users from having their entry updated/populated with the authTimestamp attribute. I suppose this could be implemented with just the check of a specific attribute (i.e. authTimestampLogging: FALSE) on the user entry. Thanks in advance as usual

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by hyc＠symas.com 24 Sep '13

24 Sep '13

openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.36 > OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.128.11.113) > > > We have an issue whereby a paged-search operation causes slapd to segfault. At > this point, I can only reproduce the issue on our production data - for which I > cannot share coredumps. I am working on isolating the issue but would appreciate > any help from openLDAP developers. > > The issue is triggered by the following search: > > ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt > '(uid=m*)' > > We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in > the sense that it may or may not happen for filters matching other sets, but it > can be reproduced reliably for any given filter/page size combination. On our > setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126. > > The issue is specific to back-mdb; backtrace points to dn2id.c: > > #0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670) > at ../../../../../servers/slapd/back-mdb/dn2id.c:738 > #1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00) > at ../../../../../servers/slapd/back-mdb/search.c:747 > > [..] > > I would greatly appreciate any help you could give me with this problem. If you backup the DB with slapcat and reload it on another server with slapadd, can you still reproduce the fault on the copy? > > > Best, > Semyon > > -- -- 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#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com 24 Sep '13

24 Sep '13

--On Monday, September 23, 2013 10:09 PM +0000 openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.36 > OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.128.11.113) > > > We have an issue whereby a paged-search operation causes slapd to > segfault. At this point, I can only reproduce the issue on our production > data - for which I cannot share coredumps. I am working on isolating the > issue but would appreciate any help from openLDAP developers. Was this database created with OpenLDAP 2.4.36 back-mdb, or did it originate with a previous release of OpenLDAP? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7705) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org 24 Sep '13

24 Sep '13

1 0

Re: (ITS#7704) OpenLDAP-Max connection retry over issue
by quanah＠zimbra.com 23 Sep '13

23 Sep '13

--On Monday, September 23, 2013 7:37 AM +0000 saurabh.4091(a)gmail.com wrote: > Full_Name: Saurabh Sudhir Bade > Version: 0.9.8a > OS: Windows server 2003 > URL: > Submission from: (NULL) (213.42.50.245) > > > Hi, > > We are using OpenLDAP to authenticate users accessing our web service. > The LDAP is configured in TIBCO Activematrix Administrator where the > services are deployed. > We get the below mentioned error quite frequently. > Error in authenticating credentials.Ldap Max connection retry over (3): > localhost:9430: Connection refused: connect > This happens because the connection pool is full and a new connection to > LDAP is unavailable . > Is there any way to increase the connection pool in LDAP? Please help me > out. Please let me know if you need any further information on this issue. Usage and configuration questions should be sent to the openldap-technical(a)openldap.org email list. The ITS system is for reporting bugs. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

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