openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 19 Oct '09

19 Oct '09

This is a multi-part message in MIME format. --------------000201000003070808090402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Attached is a backtrace with an unstripped version of slapd. If you want non-stripped version of the libc binaries, that is going to take a bit longer. > If you could get a backtrace with symbols (e.g. using an unstripped > binary) we could see some useful information. Right now, the easiest > answer would be a (subtle) bug in the "sortvals" feature. You should be > able to check by removing that statement from your configuration. This > should not require to reload the database from LDIF. The issue presented itself prior to having sortvals defined in any way. One of the first suggestions was to enable sortvals, which I did. Since this hang is present both with and without sortvals, I doubt it's related. Let me know if there is anything else I can provide. Thanks, Mark --------------000201000003070808090402 Content-Type: text/plain; name="gdb-slapd.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb-slapd.txt" GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". (gdb) ata tach 22081 Attaching to process 22081 Reading symbols from /sysvol/ldap/release/2.4.19/lib/slapd...done. Reading symbols from /sysvol/ldap/release/2.4.19/lib/libldap_r-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/libldap_r-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/liblber-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xb6dd09b0 (LWP 22081)] [New Thread 0xa114cb90 (LWP 22083)] [New Thread 0xa154cb90 (LWP 22082)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libslp.so.1...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libicuuc.so.38...done. Loaded symbols for /usr/lib/libicuuc.so.38 Reading symbols from /usr/lib/libicudata.so.38...warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 000000b4 done. Loaded symbols for /usr/lib/libicudata.so.38 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgnutls.so.26...done. Loaded symbols for /usr/lib/libgnutls.so.26 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libgcrypt.so.11...done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /usr/lib/libgpg-error.so.0...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libwrap.so.0...done. Loaded symbols for /lib/libwrap.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/back_bdb-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/back_bdb-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/syncprov-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/syncprov-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/ppolicy-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/ppolicy-2.4.so.2 0xb7dfc492 in pthread_join () from /lib/libpthread.so.0 (gdb) continue Continuing. [New Thread 0xa0c4bb90 (LWP 22105)] Program received signal SIGINT, Interrupt. [Switching to Thread 0xb6dd09b0 (LWP 22081)] 0xb7dfc492 in pthread_join () from /lib/libpthread.so.0 (gdb) backtrace full #0 0xb7dfc492 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0xb7fc2264 in ldap_pvt_thread_join (thread=2706688912, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x080715e3 in slapd_daemon () at daemon.c:2835 listener_tid = 2706688912 rc = 0 #3 0x0805e535 in main (argc=5, argv=0xbfb52dd4) at main.c:950 i = 136919464 no_detach = 0 rc = 0 urls = 0x8208028 "ldap://server:38900 ldaps://server:63600" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x8208078 "/sysvol/ldap/release/config/slapd.conf" configdir = 0x0 serverName = 0xbfb53deb "slapd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main" (gdb) info registers eax 0xfffffe00 -512 ecx 0x0 0 edx 0x5642 22082 ebx 0xa154cbd8 -1588278312 esp 0xbfb52c14 0xbfb52c14 ebp 0xbfb52c48 0xbfb52c48 esi 0x0 0 edi 0xb7e0aff4 -1210011660 eip 0xb7dfc492 0xb7dfc492 <pthread_join+274> eflags 0x200246 [ PF ZF IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) thread apply all backtrace Thread 4 (Thread 0xa0c4bb90 (LWP 22105)): #0 0xb7dff8f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0xb7fc2124 in ldap_pvt_thread_cond_wait (cond=0x822d324, mutex=0x822d30c) at thr_posix.c:277 #2 0xb7fc14d2 in ldap_int_thread_pool_wrapper (xpool=0x822d308) at tpool.c:672 #3 0xb7dfbf3b in start_thread () from /lib/libpthread.so.0 #4 0xb6fbdbee in clone () from /lib/libc.so.6 Thread 3 (Thread 0xa154cb90 (LWP 22082)): #0 0xb6fbe39c in epoll_wait () from /lib/libc.so.6 #1 0x080748ff in slapd_daemon_task (ptr=0x0) at daemon.c:2460 #2 0xb7dfbf3b in start_thread () from /lib/libpthread.so.0 #3 0xb6fbdbee in clone () from /lib/libc.so.6 Thread 2 (Thread 0xa114cb90 (LWP 22083)): #0 0xb7dff8f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0xb7fc2124 in ldap_pvt_thread_cond_wait (cond=0x822d324, mutex=0x822d30c) at thr_posix.c:277 #2 0xb7fc14d2 in ldap_int_thread_pool_wrapper (xpool=0x822d308) at tpool.c:672 #3 0xb7dfbf3b in start_thread () from /lib/libpthread.so.0 #4 0xb6fbdbee in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb6dd09b0 (LWP 22081)): #0 0xb7dfc492 in pthread_join () from /lib/libpthread.so.0 #1 0xb7fc2264 in ldap_pvt_thread_join (thread=2706688912, thread_return=0x0) at thr_posix.c:197 #2 0x080715e3 in slapd_daemon () at daemon.c:2835 #3 0x0805e535 in main (argc=5, argv=0xbfb52dd4) at main.c:950 (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /sysvol/ldap/release/2.4.19/lib/slapd, process 22081 --------------000201000003070808090402--

1 0

Re: (ITS#6334) hang during ldapmodify
by masarati＠aero.polimi.it 19 Oct '09

19 Oct '09

mkd(a)cs.brown.edu wrote: >> Does the offending value of memberUid correspond to something specially >> related to the modify operation? E.g. to the identity that is >> performing the modification, or is any other operation 'round when the >> hang occurs? > > The memberUids in this example are completely fictitious, so they don't > have any connection to the uids of real users. The thing I find > particularly intriguing is that I can change whether or not the update > is successful by simply adding or removing a single digit on the last > memberUid. If the last memberUid is 7 characters long (i.e. t247800), > the modification goes through fine. However, if the last memberUid is 8 > or more characters long (i.e. t2478000), then the operation hangs > indefinitely. If you could get a backtrace with symbols (e.g. using an unstripped binary) we could see some useful information. Right now, the easiest answer would be a (subtle) bug in the "sortvals" feature. You should be able to check by removing that statement from your configuration. This should not require to reload the database from LDIF. >> Is your GSSAPI somehow related to LDAP? > > We use GSSAPI for write authorization. I sent a copy of our slapd.conf > file a few messages back, that should show the appropriate configuration > details. > >> Are credentials actually stored in the same slapd you're modifying? > > I'm not sure I understand the question. Yes, account information is > stored in the slapd database I'm modifying, but not the specific entry > I'm modifying. The actual authorization happens through GSSAPI, so > authorization for write access is actually happening via kerberos. Does > this answer your question? The SASL/GSSAPI might result in performing lookups in slapd if information about identities is stored in the directory. If it were the case, slapd.conf would not tell, as this would result from some configuration in the GSSAPI layer. Nevertheless, given the above description of the symptoms, this seems to be unrelated. p.

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 19 Oct '09

19 Oct '09

> Does the offending value of memberUid correspond to something specially > related to the modify operation? E.g. to the identity that is > performing the modification, or is any other operation 'round when the > hang occurs? The memberUids in this example are completely fictitious, so they don't have any connection to the uids of real users. The thing I find particularly intriguing is that I can change whether or not the update is successful by simply adding or removing a single digit on the last memberUid. If the last memberUid is 7 characters long (i.e. t247800), the modification goes through fine. However, if the last memberUid is 8 or more characters long (i.e. t2478000), then the operation hangs indefinitely. > Is your GSSAPI somehow related to LDAP? We use GSSAPI for write authorization. I sent a copy of our slapd.conf file a few messages back, that should show the appropriate configuration details. > Are credentials actually stored in the same slapd you're modifying? I'm not sure I understand the question. Yes, account information is stored in the slapd database I'm modifying, but not the specific entry I'm modifying. The actual authorization happens through GSSAPI, so authorization for write access is actually happening via kerberos. Does this answer your question? Mark

1 0

Re: (ITS#6334) hang during ldapmodify
by masarati＠aero.polimi.it 19 Oct '09

19 Oct '09

mkd(a)cs.brown.edu wrote: > I'm not sure if this is a bug or we are doing something wrong. For > quite some time now, we have been using ldap to provide group > information for our linux/unix desktop machines. I believer there are > multiple methods of providing group access, this is the format we are using: > > # foobar, group, cs.brown.edu > dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu > objectClass: posixGroup > objectClass: top > cn: ugrad > gidNumber: 1200 > memberUid: t1 > memberUid: t2 > memberUid: t3 > memberUid: t4 > memberUid: t5 > . > . > . > > Up until recently, this had been working great. We are now experiencing > hangs whenever we try to update the records with one particular group. > I think the hangs are occur when we try to feed too much data to > ldapmodify at a time. For instance, if I have the above group and try > to apply the following ldif file: > > dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu > changetype: modify > replace: memberUid > memberUid: t1 > memberUid: t2 > memberUid: t3 > memberUid: t4 > memberUid: t5 > memberUid: t6 > memberUid: t7 > memberUid: t8 > memberUid: t9 > . > . > . > memberUid: t2477 > memberUid: t2478 > memberUid: t2479 Does the offending value of memberUid correspond to something specially related to the modify operation? E.g. to the identity that is performing the modification, or is any other operation 'round when the hang occurs? Is your GSSAPI somehow related to LDAP? Are credentials actually stored in the same slapd you're modifying? p.

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 19 Oct '09

19 Oct '09

Matthew, Sorry, I forgot to include the slapd server log as requested. > This looks like you added -d to your ldapmodify. More useful here would > be server logs; try running slapd with -d 263 so we can see more of what > the server is trying. (1+2+4+256) Oct 19 12:08:02 server slapd[15863]: @(#) $OpenLDAP: slapd 2.4.19 (Oct 15 2009 16:33:37) $ ^Imkd@build:/sysvol/ldap/src/openldap-2.4.19/servers/slapd Oct 19 12:08:04 server slapd[15863]: slapd starting Oct 19 12:08:08 server slapd[15863]: conn=0 fd=13 ACCEPT from IP=<IP>:34472 (IP=<IP>:63600) Oct 19 12:08:08 server slapd[15863]: conn=0 fd=13 TLS established tls_ssf=128 ssf=128 Oct 19 12:08:08 server slapd[15863]: conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 19 12:08:08 server slapd[15863]: conn=0 op=0 SRCH attr=supportedSASLMechanisms Oct 19 12:08:08 server slapd[15863]: conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 19 12:08:08 server slapd[15863]: conn=0 op=1 BIND dn="" method=163 Oct 19 12:08:08 server slapd[15863]: conn=0 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required Oct 19 12:08:08 server slapd[15863]: conn=0 op=2 BIND dn="" method=163 Oct 19 12:08:08 server slapd[15863]: conn=0 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required Oct 19 12:08:08 server slapd[15863]: connection_input: conn=0 deferring operation: binding Oct 19 12:08:08 server slapd[15863]: conn=0 op=3 BIND dn="" method=163 Oct 19 12:08:08 server slapd[15863]: conn=0 op=3 BIND authcid="user/root(a)cs.brown.edu" authzid="user/root(a)cs.brown.edu" Oct 19 12:08:08 server slapd[15863]: conn=0 op=3 BIND dn="uid=user/root,cn=cs.brown.edu,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128 Oct 19 12:08:08 server slapd[15863]: conn=0 op=3 RESULT tag=97 err=0 text= Oct 19 12:11:57 server slapd[15863]: conn=0 fd=13 closed (connection lost) Unfortunately, it doesn't provide much information at this debug level, should I crank it up further? Thanks, Mark

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 19 Oct '09

19 Oct '09

This is a multi-part message in MIME format. --------------030103000807090505050604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Matthew, Attached is a first shot at the backtrace. It looks like I have many missing symbol tables, so I'm not sure how useful this will be to you. The hang appears to be in pthread, so it may not strictly be a slapd issue after all. As a temporary measure, I'm looking at a workaround on our end that breaks up the replace calls into adds and deletes. This may let us work around this entire problem. It doesn't address the underlying issue though. Thanks, Mark > Can you attach a gdb backtrace taken during the hang? (thread apply all > backtrace full) --------------030103000807090505050604 Content-Type: text/plain; name="gdb-slapd.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb-slapd.txt" GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". (gdb) attach 14884 Attaching to process 14884 Reading symbols from /sysvol/ldap/release/2.4.19/lib/slapd...(no debugging symbols found)...done. Reading symbols from /sysvol/ldap/release/2.4.19/lib/libldap_r-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/libldap_r-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/liblber-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xb6dc79b0 (LWP 14884)] [New Thread 0xa1143b90 (LWP 14886)] [New Thread 0xa1543b90 (LWP 14885)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libslp.so.1...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libicuuc.so.38...done. Loaded symbols for /usr/lib/libicuuc.so.38 Reading symbols from /usr/lib/libicudata.so.38...warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 000000b4 done. Loaded symbols for /usr/lib/libicudata.so.38 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgnutls.so.26...done. Loaded symbols for /usr/lib/libgnutls.so.26 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libgcrypt.so.11...done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /usr/lib/libgpg-error.so.0...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libwrap.so.0...done. Loaded symbols for /lib/libwrap.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/back_bdb-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/back_bdb-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/syncprov-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/syncprov-2.4.so.2 Reading symbols from /sysvol/ldap/release/2.4.19/lib/ldap/ppolicy-2.4.so.2...done. Loaded symbols for /sysvol/ldap/release/2.4.19/lib/ldap/ppolicy-2.4.so.2 0xb7df3492 in pthread_join () from /lib/libpthread.so.0 (gdb) continue Continuing. [New Thread 0xa0c42b90 (LWP 15033)] Program received signal SIGINT, Interrupt. [Switching to Thread 0xb6dc79b0 (LWP 14884)] 0xb7df3492 in pthread_join () from /lib/libpthread.so.0 (gdb) backtracer full #0 0xb7df3492 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0xb7fb9264 in ldap_pvt_thread_join (thread=2706652048, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x080715e3 in slapd_daemon () No symbol table info available. #3 0x0805e535 in main () No symbol table info available. (gdb) info registers eax 0xfffffe00 -512 ecx 0x0 0 edx 0x3a25 14885 ebx 0xa1543bd8 -1588315176 esp 0xbfff9274 0xbfff9274 ebp 0xbfff92a8 0xbfff92a8 esi 0x0 0 edi 0xb7e01ff4 -1210048524 eip 0xb7df3492 0xb7df3492 <pthread_join+274> eflags 0x200246 [ PF ZF IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) thread apply all backtrace Thread 4 (Thread 0xa0c42b90 (LWP 15033)): #0 0xb7df68f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0xb7fb9124 in ldap_pvt_thread_cond_wait (cond=0x9ca3324, mutex=0x9ca330c) at thr_posix.c:277 #2 0xb7fb84d2 in ldap_int_thread_pool_wrapper (xpool=0x9ca3308) at tpool.c:672 #3 0xb7df2f3b in start_thread () from /lib/libpthread.so.0 #4 0xb6fb4bee in clone () from /lib/libc.so.6 Thread 3 (Thread 0xa1543b90 (LWP 14885)): #0 0xb6fb539c in epoll_wait () from /lib/libc.so.6 #1 0x080748ff in ?? () #2 0x00000006 in ?? () #3 0x09c846c0 in ?? () #4 0x00000400 in ?? () #5 0x000bb800 in ?? () #6 0x00000000 in ?? () Thread 2 (Thread 0xa1143b90 (LWP 14886)): #0 0xb7df68f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0xb7fb9124 in ldap_pvt_thread_cond_wait (cond=0x9ca3324, mutex=0x9ca330c) at thr_posix.c:277 #2 0xb7fb84d2 in ldap_int_thread_pool_wrapper (xpool=0x9ca3308) at tpool.c:672 #3 0xb7df2f3b in start_thread () from /lib/libpthread.so.0 #4 0xb6fb4bee in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb6dc79b0 (LWP 14884)): #0 0xb7df3492 in pthread_join () from /lib/libpthread.so.0 #1 0xb7fb9264 in ldap_pvt_thread_join (thread=2706652048, thread_return=0x0) at thr_posix.c:197 #2 0x080715e3 in slapd_daemon () #3 0x0805e535 in main () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /sysvol/ldap/release/2.4.19/lib/slapd, process 14884 --------------030103000807090505050604--

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 19 Oct '09

19 Oct '09

This is a multi-part message in MIME format. --------------040100030100010805040809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a sanitized copy of my slapd.conf. I'm still working on the logs and gdb backtrace. Let me know if you notice anything out of sorts. Thanks! Mark masarati(a)aero.polimi.it wrote: >> Matthew and Hallvard, >> >> Matthew Backes wrote: >>> Large collections of values can be slow for some uses; have you looked >>> at the sortvals option? (needs a db reload with slapcat+slapadd) >> Thanks for your suggestion to add the sortvals option. I've done so and >> still experience the hangs. >> >>>> memberUid: t2479 >>> That doesn't seem terribly large, no. sortvals is more pertinent if you >>> have 100k+ values on the attribute... >> Exactly what I was thinking. This doesn't seem like a really large >> number, but it's consistently hanging for us. > > A consistent hang calls for some deadlock. Your configuration might be > tweaking some strange interoperation of functionalities that result in the > deadlock. So, rather than the logs, the configuration would be of > paramount interest. We are obviously looking for details, so don't omit > anything; rather sanitize sensitive information, like passwords. I'm > specifically thinking about some strange interoperation between databases, > overlays, ACLs and so. > > p. > --------------040100030100010805040809 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/krb5-kdc.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/automount.schema include /etc/ldap/schema/samba.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.master.pid # List of arguments that were passed to the server argsfile /var/run/slapd.master.args # Read slapd.conf(5) for possible values loglevel stats sync # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov moduleload ppolicy ####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend <other> ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb # The base of your directory in database #1 suffix "dc=cs,dc=brown,dc=edu" # number of entries to keep in cache cachesize 10000 # time between database checkpoints checkpoint 128 15 # Where the database file are physically stored for database #1 directory "/sysvol/ldap/db" # Indexing options for database #1 index default eq index cn,sn,givenName index uid,uidNumber,gidNumber,memberNisNetGroup index automountKey,automountMapName,memberUid,uniqueMember,homeDirectory index contextCSN,entryCSN,entryUUID,objectClass index mail eq,sub # multi-valued attributes that should always be maintained in sorted order sortvals memberUid sortvals nisNetgroupTriple # Max number of anonymous sessions conn_max_pending 1000 # Save the time that the entry gets modified, for database #1 lastmod on overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 100 ###################################################################### # CS dept config ###################################################################### # TLS Config TLSCertificateFile /sysvol/ldap/config/ldapmaster-cert.pem TLSCertificateKeyFile /sysvol/ldap/config/ldapmaster-key.pem TLSCACertificateFile /usr/share/ca-certificates/cs.brown.edu/cs.brown.edu.crt TLSVerifyClient allow # CS dept SASL config sasl-realm cs.brown.edu sasl-host ldapmaster.cs.brown.edu # This is a bit of a hack to restrict the SASL mechanisms that the server # advertises to just GSSAPI. Otherwise it also advertises DIGEST-MD5, # which the clients prefer. Then you have to add "-Y GSAPPI" to all of # your ldapsearch/ldapmodify command lines, which is annoying. The default # for this is noanonymous,noplain so the addition of noactive is what makes # DIGEST-MD5 and others go away. sasl-secprops noanonymous,noplain,noactive # Map SASL authentication DNs to LDAP DNs. This leaves <username>/root # principals untouched saslRegexp uid=([^/]*),cn=cs.brown.edu,cn=GSSAPI,cn=auth uid=$1,ou=people,dc=cs,dc=brown,dc=edu # This should be a ^ plus, not a star, but slapd won't accept it # Access controls access to * attrs=userPassword by ssf=128 anonymous auth by ssf=128 dn.regex="uid=.*/root,cn=cs.brown.edu,cn=GSSAPI,cn=auth" write by ssf=128 dn="cn=sync,dc=cs,dc=brown,dc=edu" write by ssf=128 self write by * none # The */root dn has full write access, everyone else can read everything. access to * by ssf=128 dn.regex="uid=.*/root,cn=cs.brown.edu,cn=GSSAPI,cn=auth" write by ssf=128 dn="uid=.*,ou=people,dc=cs,dc=brown,dc=edu,cn=GSSAPI,cn=auth" read by * read # Specify default password policies overlay ppolicy ppolicy_default "cn=password,ou=policies,dc=cs,dc=brown,dc=edu" password-hash {SSHA} sizelimit unlimited timelimit unlimited --------------040100030100010805040809--

1 0

(ITS#6336) filedescriptor leak libnspr4.so
by liedekef＠telenet.be 18 Oct '09

18 Oct '09

Full_Name: Franky Van Liedekerke Version: openldap-servers-2.4.15-6.fc11.i586 OS: Fedora 11 URL: Submission from: (NULL) (84.197.109.39) I'm running openldap version 2.4.15-6 (rpm) on a up-to-date fedora 11 server. After some time, my openldap stops responding, and I narrowed it down to a file descriptor leak, where openldap keeps /lib/libnspr4.so open X times untill it runs out of file descriptors. It seems to be related to this redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=502133 Below is a small strace of 1 openldap thread where it is clearly shown that a thread opens up libnspr4.so but never closes it again. Unfortunately, I can't reproduce this with any ldap query, so it seems to be related to the thread lib itself ... [pid 24483] <... futex resumed> ) = 0 [pid 24483] futex(0xffb6cc, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 68, MSG_NOSIGNAL) = 68 [pid 24483] time(NULL) = 1255876596 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 83, MSG_NOSIGNAL) = 83 [pid 24483] read(13, "09\2\2\0\220`3"..., 8) = 8 [pid 24483] read(13, "\2\1\3\4\"cn=Sandra Gyles,ou=users,o=g"..., 51) = 51 [pid 24483] time(NULL) = 1255876596 [pid 24483] read(13, 0x1088213, 8) = -1 EAGAIN (Resource temporarily unavailable) [pid 24483] epoll_ctl(6, EPOLL_CTL_MOD, 13, {EPOLLIN, {u32=16643796, u64=16643796}}) = 0 [pid 24483] write(5, "0"..., 1) = 1 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 57, MSG_NOSIGNAL) = 57 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 92, MSG_NOSIGNAL) = 92 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 130, MSG_NOSIGNAL) = 130 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 105, MSG_NOSIGNAL) = 105 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 86, MSG_NOSIGNAL) = 86 [pid 24483] open("/etc/ld.so.cache", O_RDONLY) = 38 [pid 24483] fstat64(38, {st_mode=S_IFREG|0644, st_size=57720, ...}) = 0 [pid 24483] mmap2(NULL, 57720, PROT_READ, MAP_PRIVATE, 38, 0) = 0xa12ec000 [pid 24483] close(38) = 0 [pid 24483] open("/lib/libnspr4.so", O_RDONLY) = 38 [pid 24483] read(38, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\10`\0054\0\0\0\214"..., 512) = 512 [pid 24483] fstat64(38, {st_mode=S_IFREG|0755, st_size=232252, ...}) = 0 [pid 24483] munmap(0xa12ec000, 57720) = 0 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 130, MSG_NOSIGNAL) = 130 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 71, MSG_NOSIGNAL) = 71 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 78, MSG_NOSIGNAL) = 78 [pid 24483] write(13, "0\r\2\2\0\220a\7\n\1\0\4\0\4\0"..., 15) = 15 [pid 24483] futex(0xffb6e8, FUTEX_WAIT_PRIVATE, 434, NULL <unfinished ...>

1 0

Re: (ITS#6334) hang during ldapmodify
by masarati＠aero.polimi.it 17 Oct '09

17 Oct '09

> Matthew and Hallvard, > > Matthew Backes wrote: >> Large collections of values can be slow for some uses; have you looked >> at the sortvals option? (needs a db reload with slapcat+slapadd) > > Thanks for your suggestion to add the sortvals option. I've done so and > still experience the hangs. > >>> memberUid: t2479 >> >> That doesn't seem terribly large, no. sortvals is more pertinent if you >> have 100k+ values on the attribute... > > Exactly what I was thinking. This doesn't seem like a really large > number, but it's consistently hanging for us. A consistent hang calls for some deadlock. Your configuration might be tweaking some strange interoperation of functionalities that result in the deadlock. So, rather than the logs, the configuration would be of paramount interest. We are obviously looking for details, so don't omit anything; rather sanitize sensitive information, like passwords. I'm specifically thinking about some strange interoperation between databases, overlays, ACLs and so. p.

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 16 Oct '09

16 Oct '09

The ones BEFORE that spanned a few days. How about the fact that I had to open ANOTHER ticket to someone's attention to get THIS ONE "figured out"? THIS was what irritated me. And from the looks of things, I was wrong: 6320 is the result of Unreliable Synchronization, the deadlocking issue made it worse, but is a separate issue. So you still have a ticket (6320) that was unresolved. Yes, I said don't bother -- but how about the few posts before that, with me asking for more help and getting no responses? I had to make an ASSUMPTION, based on Pierangelo's suggestion. Given what he said, and given what I'd observed, it seemed a valid assumption, but was not. The problem is that OpenLDAP has SO MANY PROBLEMS, its almost impossible to discern ONE from ANOTHER unless you WORK at the OpenLDAP foundation. Thats unreasonable and I don't have time for two jobs. Anyways, Quanah, I think we should just drop this now, as its going to get into a screaming match regarding the following issues: * Unreliable OpenLDAP releases * Lackluster/falsely-advertised SyncRepl behavior * Lengthy-delays in helpful ticket responses * Paid-version does not mitigate "free" version issues * My frustration with OpenLDAP as a whole I don't want to be Master Yoda's age by the time this stuff is resolved. And I don't want to spend the rest of this year debating it with you. So please, just drop it.

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