openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

Re: (ITS#6855) Suggested improvements to OpenLDAP Admin Guide preface
by hyc＠symas.com 04 Mar '11

04 Mar '11

gerv(a)mozilla.org wrote: > Full_Name: Gervase Markham > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.45.122.200) > > > Following a discussion on the mailing list, I submit the following as a > suggestion for improvement to the Preface of the Admin Guide, to make it clear > that there are other documentation resources which should be read. Thanks. I've committed some of this suggestion to CVS HEAD. I would expect an experienced sysadmin to already know which manpage sections are relevant, and I don't believe a sysadmin needs to read the API documentation. > <snip> > This document is not a complete guide to its subject matter; the man pages are > the definitive documentation for OpenLDAP software. For best results, you should > use those installed on your system, which will match your version of OpenLDAP. > But they are also available on the web from the following links: > > OpenLDAP API: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> > </ul> > > OpenLDAP configuration: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> > </ul> > > OpenLDAP command line tools: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) > </ul> > > Gerv > -- -- 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#6853) slapadd/slapindex -q hang
by hyc＠symas.com 04 Mar '11

04 Mar '11

dhawes(a)vt.edu wrote: > On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: >> This indicates that the trickle task is still waiting for a signal on its >> condition variable. Which is a bit odd since bdb_tool_entry_close() already >> signals it before slap_tool_destroy() is called. >> >> It might be illuminating to run slapadd under gdb with a breakpoint on >> bdb_tool_entry_close(), and singlestep through the first few lines of that >> function where it issues the signal, and see if the trickle task actually >> reacts or not. > > Setting a breakpoint on bdb_tool_entry_close() and then either > continuing or stepping through the function allows slapadd to exit cleanly. A fix for this is now in HEAD, please test. back-bdb/tools.c 1.140 -- -- 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#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 04 Mar '11

04 Mar '11

On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message "Closing >>>> DB..." is printed and then the application hangs indefinitely. Removing >>>> the -q option allows the application to complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, >> ptr=<value optimized out>) at tools.c:1253 >> #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> #4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> #5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() already > signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of that > function where it issues the signal, and see if the trickle task actually > reacts or not. Setting a breakpoint on bdb_tool_entry_close() and then either continuing or stepping through the function allows slapadd to exit cleanly.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 04 Mar '11

04 Mar '11

--On Friday, March 04, 2011 9:08 PM +0000 hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message >>>> "Closing DB..." is printed and then the application hangs >>>> indefinitely. Removing the -q option allows the application to >>>> complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1253 >> # 2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> # 3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> # 4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> # 5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() > already signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of > that function where it issues the signal, and see if the trickle task > actually reacts or not. > >> Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x0000000000506223 in ldap_pvt_thread_pool_destroy >> (tpool=0x7ffffffed658, >> run_pending=<value optimized out>) at tpool.c:582 >> # 2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at >> # tpool.c:181 3 0x00000000005050a9 in ldap_pvt_thread_destroy () at >> # threads.c:70 4 0x0000000000466059 in slap_destroy () at init.c:273 >> # 5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 >> # 6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) >> at slapadd.c:606 >> # 7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at >> # main.c:407 We are seeing numerous reports of this occurring with Zimbra after using OpenLDAP 2.4.23 + the multi-core fix (ITS#6660) --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#6850) sssvlv can segfault when releasing multiple requests by conn
by hyc＠symas.com 04 Mar '11

04 Mar '11

raphael.ouazana(a)linagora.com wrote: > Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a écrit : >> >>> The following patch >> >> Please upload patches according to >> <http://www.openldap.org/devel/contributing.html#submitting>. > > Sorry, it seems to be my fault. Here it is: > ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort… Thanks for the patch. While you're at it, would you be able to create a test script for sssvlv to use in our test suite? -- -- 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#6853) slapadd/slapindex -q hang
by hyc＠symas.com 04 Mar '11

04 Mar '11

dhawes(a)vt.edu wrote: > On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >> >>> Full_Name: David Hawes >>> Version: 2.4.24 >>> OS: Ubuntu 10.04 >>> URL: >>> Submission from: (NULL) (128.173.39.26) >>> >>> >>> When using slapadd or slapindex with the -q option, the message "Closing >>> DB..." is printed and then the application hangs indefinitely. Removing >>> the -q option allows the application to complete without issue. >>> >>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >> >> I would ask you provide a full backtrace of the slapadd process after it >> has hung. Otherwise, this report isn't of much use. >> >> Also, if you are using the Ubuntu patches for OpenLDAP with your >> OpenLDAP build, you are including a known database-corrupting patch. >> Since you don't say how you built OpenLDAP, it is impossible for us to >> know if you did this or not. > > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): > > (gdb) thread apply all bt > > Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1253 > #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( > xpool=<value optimized out>) at tpool.c:685 > #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 > #4 0x00007ffff677970d in clone () from /lib/libc.so.6 > #5 0x0000000000000000 in ?? () This indicates that the trickle task is still waiting for a signal on its condition variable. Which is a bit odd since bdb_tool_entry_close() already signals it before slap_tool_destroy() is called. It might be illuminating to run slapadd under gdb with a breakpoint on bdb_tool_entry_close(), and singlestep through the first few lines of that function where it issues the signal, and see if the trickle task actually reacts or not. > Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy > (tpool=0x7ffffffed658, > run_pending=<value optimized out>) at tpool.c:582 > #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 > #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 > #4 0x0000000000466059 in slap_destroy () at init.c:273 > #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 > #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) > at slapadd.c:606 > #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 -- -- 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#6854) When login from one application, "error=49" error show up, but other application's login are all right.
by quanah＠zimbra.com 04 Mar '11

04 Mar '11

--On Friday, March 04, 2011 11:01 AM +0000 mahaoboy(a)gmail.com wrote: > Full_Name: hao ma > Version: 2.3.43 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.161.106.50) > > > We have configured Openldap as our user info repository for all our > applications.(include Atlassian JIRA,Confluence,Fisheye,Crowd). Usage questions should be directed to openldap-technical(a)openldap.org. The ITS system is for reporting bugs only. I would also note that OpenLDAP 2.3 is no longer supported, so bug reports for that release will be ignored. OpenLDAP 2.4.23 is the current stable release. --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#6855) Suggested improvements to OpenLDAP Admin Guide preface
by gerv＠mozilla.org 04 Mar '11

04 Mar '11

Full_Name: Gervase Markham Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.45.122.200) Following a discussion on the mailing list, I submit the following as a suggestion for improvement to the Preface of the Admin Guide, to make it clear that there are other documentation resources which should be read. <snip> This document is not a complete guide to its subject matter; the man pages are the definitive documentation for OpenLDAP software. For best results, you should use those installed on your system, which will match your version of OpenLDAP. But they are also available on the web from the following links: OpenLDAP API: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> </ul> OpenLDAP configuration: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> </ul> OpenLDAP command line tools: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) </ul> Gerv

1 0

(ITS#6854) When login from one application, "error=49" error show up, but other application's login are all right.
by mahaoboy＠gmail.com 04 Mar '11

04 Mar '11

Full_Name: hao ma Version: 2.3.43 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.161.106.50) We have configured Openldap as our user info repository for all our applications.(include Atlassian JIRA,Confluence,Fisheye,Crowd). Then we met an very strange user. This user can logged in confluence successfully, but when could not log in fisheye. And in a little chance, he could log in fisheye correctly. Firstly , we try to find problem from these applications. And all clue point to Openldap server. So we configure Openldap Loglever as -1. And we recorded two different log of logging in confluence and logging in fisheye. Log of confluence logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search daemon: activity on 1 descriptor >>> dnPrettyNormal: <ou=eejira,o=nsn> daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter daemon: epoll: listen=8 active_threads=0 tvp=NULL AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8052 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8052 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8052 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8053 tag=101 err=0 conn=5 op=8052 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=8 fd=20 ACCEPT from IP=87.254.208.143:42569 (IP=0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=8 connection_read(20): checking for input on id=8 do_bind >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=8 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) conn=8 op=0 BIND dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=jirasupport,ou=people,ou=eejira,o=nsn" to "cn=jirasupport,ou=People,ou=eejira,o=nsn" send_ldap_result: conn=8 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 conn=8 op=0 RESULT tag=97 err=0 text= daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL Log of fisheye logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search >>> dnPrettyNormal: <ou=eejira,o=nsn> <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8051 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 entry_decode: "cn=jirasupport,ou=People,ou=eejira,o=nsn" <= entry_decode(cn=jirasupport,ou=People,ou=eejira,o=nsn) => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8051 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8051 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8052 tag=101 err=0 conn=5 op=8051 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=7 fd=20 ACCEPT from IP=87.254.208.143:39622 (IP=0.0.0.0:389) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 do_bind daemon: activity on 1 descriptor daemon: activity on: >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=7 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") daemon: epoll: listen=7 active_threads=0 tvp=NULL => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested daemon: epoll: listen=8 active_threads=0 tvp=NULL => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) send_ldap_result: conn=7 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 conn=7 op=0 RESULT tag=97 err=49 text= daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 ber_get_next on fd 20 failed errno=0 (Success) connection_read(20): input error=-2 id=7, closing. connection_closing: readying conn=7 sd=20 for close connection_close: conn=7 sd=-1 daemon: removing 20 conn=7 fd=20 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL And other users are all right for logging in all applications. Do you have any advice for this problem? Thanks a lot.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 8:50 PM +0000 dhawes(a)vt.edu wrote: > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): My personal experience with gcc & openldap is that building an optimized version of OpenLDAP is an extremely bad idea, as gcc makes very bad choices. --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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011