- openldap-bugs - openldap.org

Re: (ITS#6338) dnParent(x, x) can remove \0-termination
by h.b.furuseth＠usit.uio.no 20 Oct '09

20 Oct '09

masarati(a)aero.polimi.it writes: >> struct berval x = BER_BVC("cn=foo"); >> dnParent(x, x); >> keeps x.bv_val pointing at "cn=foo" instead of at the \0 >> behind it. bv_len is correctly set to 0 though. > > Could be sort of intentional. As far as I remember, dnParent() is > supposed to leave the second argument untouched, as it is often used > on read-only data. s/second/first/, but yes. With pdn=dn though (both args equal), the code first reset pdn->bv_val and then used that value. Swapping it makes more sense, and ensures that the output value is independent of whether or not pdn == dn. > Probably, the most appropriate fix consists in passing > a temporary as the first argument. No, the comment above the function says that pdn can be == dn. -- Hallvard

1 0

(ITS#6341) slapd crashing when deleting and re-adding the last object
by ralf＠OpenLDAP.org 20 Oct '09

20 Oct '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.30.227) Submitted by: ralf slapd in current HEAD and RE24 crashes when the last object from the database is deleted and re-added. Valgrind gives me this (during the ldapadd operation): ==11646== Invalid read of size 8 ==11646== at 0x52E4F2: bdb_cache_lru_link (cache.c:137) ==11646== by 0x530762: hdb_cache_add (cache.c:1191) ==11646== by 0x52C8D9: hdb_add (add.c:484) ==11646== by 0x44A43D: fe_op_add (add.c:334) ==11646== by 0x449DB0: do_add (add.c:194) ==11646== by 0x4410E6: connection_operation (connection.c:1123) ==11646== by 0x441672: connection_read_thread (connection.c:1259) ==11646== by 0x4E3C51C: ldap_int_thread_pool_wrapper (tpool.c:685) ==11646== by 0x6EB206F: start_thread (in /lib64/libpthread-2.9.so) ==11646== by 0x719A10C: clone (in /lib64/libc-2.9.so) ==11646== Address 0x9b25740 is 128 bytes inside a block of size 144 free'd ==11646== at 0x4C243AF: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==11646== by 0x5091C09: ber_memfree_x (memory.c:152) ==11646== by 0x465624: ch_free (ch_malloc.c:139) ==11646== by 0x52E493: bdb_cache_entryinfo_free (cache.c:104) ==11646== by 0x530E5A: hdb_cache_delete_cleanup (cache.c:1419) ==11646== by 0x5369A9: hdb_delete (delete.c:575) ==11646== by 0x462FDD: fe_op_delete (delete.c:174) ==11646== by 0x462C6C: do_delete (delete.c:95) ==11646== by 0x4410E6: connection_operation (connection.c:1123) ==11646== by 0x4E3C51C: ldap_int_thread_pool_wrapper (tpool.c:685) ==11646== by 0x6EB206F: start_thread (in /lib64/libpthread-2.9.so) ==11646== by 0x719A10C: clone (in /lib64/libc-2.9.so) Further investigation with gdb showed that bdb->bi_cache.c_lrutail points to free'd memory after the last object is removed from the database, which results in the crash when trying to access that memory during the add operation. I am currently working on a fix. Will submit it to HEAD later today.

1 0

(ITS#6340) What should I do it well?
by sunjian.xa＠gmail.com 20 Oct '09

20 Oct '09

Full_Name: sunjian Version: 2.4.16 OS: CentOS 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.114.169.6) hello, I am developing a ldap client program with kerberos V5 authentication under CentOS 4.7. Heimdal 0.7.2 is used for KDC, and OpenLDAP 2.4.16 for heimdal's backend. Cyrus SASL 2.1.22, OpenSSL 0.9.8b and BerkeleyDB 4.4.20 are also used. I compile OpenLDAP as follow, $env ol_enable_kbind=yes ./configure --prefix=/usr --localstatedir=/var/openldap --enable-syslog --enable-local --with-cyrus-sasl --with-threads --with-tls --with-kerberos --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-hdb --enable-ldap --enable-monitor --enable-dyngroup --enable-proxycache $make depend $make make[3]: Entering directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c -o bind.o bind.c: In function `bdb_bind': bind.c:154: error: syntax error before "goto" bind.c:161: error: syntax error before "goto" bind.c:176: error: syntax error before "goto" make[3]: *** [bind.lo] Error 1 make[3]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/xk/download/openldap-2.3.24/servers' make: *** [all-common] Error 1 Some one else told me that compiled with kbind, OpenLDAP should be patched and autoconf redone. Is that true? How to do in detail? If no kbind.o support, I have established the whole enviroment successfully. And the system works well. But I have to develop client program myself, so I need function ldap_kerberos_bind_s whose symbol included in kbind.o, then error occurs. Thanks.

1 0

Re: (ITS#6338) dnParent(x, x) can remove \0-termination
by masarati＠aero.polimi.it 20 Oct '09

20 Oct '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > This: > struct berval x = BER_BVC("cn=foo"); > dnParent(x, x); > keeps x.bv_val pointing at "cn=foo" instead of at the \0 > behind it. bv_len is correctly set to 0 though. Could be sort of intentional. As far as I remember, dnParent() is supposed to leave the second argument untouched, as it is often used on read-only data. Probably, the most appropriate fix consists in passing a temporary as the first argument. p.

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

--On Monday, October 19, 2009 3:46 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > This problem is also seen with Net::LDAPapi perl module, so it is library > rather than tool specific. It seems to be SASL specific as well (Stanford uses GSSAPI binds). I modified one of the problematic servers to have access to * by * read as its only ACL, and then did two searches. One using SASL/GSSAPI and one using anonymous query. The anonymous query succeeded across multiple runs. The SASL/GSSAPI query failed to complete. This was with a 2.4.19 ldapsearch binary against a remote 2.4.19 slapd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

Doing more investigation of this ITS reveals it appears to be related specifically to the version of ldapsearch used, and whether or not the connection actually goes over the network. Specifically, the result I see is: ldap_chkResponseList ld 0x510190 msgid -1 all 0 ldap_chkResponseList returns ld 0x510190 NULL ldap_int_select read1msg: ld 0x510190 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=39 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 9d cb c2 05 ................ 0010: 43 a1 60 68 a0 f7 33 da d1 37 2f d8 21 4a 75 87 C.`h..3..7/.!Ju. 0020: b1 d8 73 41 ea 20 6b ..sA. k Working search shows: ldap_chkResponseList ld 2f798 msgid -1 all 0 ldap_chkResponseList returns ld 2f798 NULL ldap_int_select read1msg: ld 2f798 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=82 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 6b be 1b 98 ............k... 0010: 17 5f 4a 09 70 15 23 cc 32 9f 71 6f eb 6e d2 66 ._J.p.#.2.qo.n.f 0020: b1 9a 56 61 4b 0a 64 83 ec a3 95 27 7d 07 87 5c ..VaK.d....'}..\ 0030: aa 37 26 a6 43 23 98 ab 60 e0 35 3b 7a f6 89 c2 .7&.C#..`.5;z... 0040: ca 7a 47 ec c2 0a 28 63 50 a8 16 da ae 55 fd 11 .zG...(cP....U.. 0050: ab 15 .. at which point it hangs. I've tried the following things: ldapsearch version 2.3.13 from a Solaris box. Searching with this version of ldapsearch never hangs, regardless of host location (remote machine room in Livermore, or local stanford machine room). ldapsearch version 2.4.11 from a linux box to ldap1 (2.4.19 server) hangs. These two boxes are in different locations/networks. ldapsearch 2.3.35 from ldap2 to ldap1 (2.4.19 server) hangs. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap2 (2.3.35 server) does *not* hang. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap-liv1 (2.4.19 server) hangs. So does the reverse direction. These two boxes are in very different locations. This problem is also seen with Net::LDAPapi perl module, so it is library rather than tool specific. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

--On Monday, October 19, 2009 10:32 PM +0000 openldap-its(a)OpenLDAP.org wrote: s/exist/exit --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Executing ldapsearch -V to get the version information correctly prints it, but then proceeds to execute a search.

1 0

(ITS#6332)
by l.mierzwa＠gmail.com 19 Oct '09

19 Oct '09

Using accesslog overlay fixed my issues, without that not every change on=20 master is picked up by slaves. =C5=81ukasz

1 0

(ITS#6338) dnParent(x, x) can remove \0-termination
by h.b.furuseth＠usit.uio.no 19 Oct '09

19 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This: struct berval x = BER_BVC("cn=foo"); dnParent(x, x); keeps x.bv_val pointing at "cn=foo" instead of at the \0 behind it. bv_len is correctly set to 0 though. Fixing.

1 0

Re: (ITS#6334) hang during ldapmodify
by rein＠OpenLDAP.org 19 Oct '09

19 Oct '09

mkd(a)cs.brown.edu wrote: > Let me know if there is anything else I can provide. Can you verify that the entire modify operation actually reaches the server? There is no sign of it being active in the stack trace, nor does the debug output show anything related to it, so I'm wondering if there is some network equipment between your client and server that causes too big requests to be dropped. slapd will also drop the connection if it receives too big requests, but given the data you provide you should be way below the default sockbuf_max_incomping_auth value. Please provide a "-d 271" output from slapd, it should be much more than the log you sent earlier. Your logs looks like syslog logs, while the debug output goes to stderr. Note: This log includes the content of the entire packets sent to/from the server, so you may wish to remove the output related to the bind requests. Rein

1 0

ITS#6337
by masarati＠aero.polimi.it 19 Oct '09

19 Oct '09

What seems to happen is that bind's response is sent outside the backend, by the frontend itself. As a consequence, back-relay's callback structure, which is located on the stack, is dangling at the moment it is used. p.

1 0

(ITS#6337) Combining back-relay/slapo-rwm and back-hdb/slapo-accesslog seg faults
by michael＠stroeder.com 19 Oct '09

19 Oct '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.81.160) HI! Consider two backends: db1: The real database back-hdb where actions are logged via slapo-accesslog to a separate back-hdb database. db2: back-relay with suffix rewriting rules with slapo-rwm which maps requests to the back-hdb database. Now binding as the rootdn of db2 leads to a seg fault. Canned config and gdb backtrace will follow...

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. --------------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

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

16 Oct '09

--On Friday, October 16, 2009 8:56 PM +0000 j(a)telepaths.org wrote: > Overall declining bugs, yes. > > Bugs I HAVE personally observed since 2.3 -> 2.4 = INCREASING. > > We currently use OpenLDAP 2.3x with Delta SyncRepl (single master) > with no issues. > > If I take that same setup into OL 2.4x, the problems get VERY BAD: > > * Data stops being replicated RANDOMLY > * Writes stop 'getting honored' > * Binary crashes > * Man pages make me want to light myself on fire. > > I realize this software is free. Obviously. > > I realize this software is supported by volunteers. But my old > ticket, 6320, is getting no more attention from anyone. I need > something better than that. I have a PROBLEM. And people STOPPED > RESPONDING TO ME. This is --> unacceptable <-- The last email you sent to ITS#6320 was: Followup 25 Download message Subject: Re: (ITS#6320) From: Jeff Doyle <j(a)telepaths.org> Date: Wed, 14 Oct 2009 18:27:31 -0700 To: openldap-its(a)OpenLDAP.org OK, for anyone following this thread, please refer to ITS #6331, as I believe this issue may not be a "replication issue" at all, rather a deadlock PREVENTING replication. Might as well close this ticket, thanks for everyone's help. Jeff Why would you expect anyone to respond? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

16 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. >> The update simply hangs. Tossing a "-d 65535" shows that the process is >> sitting in loop spitting out messages similar to: > >> ldap_int_select > > 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) > >> I'm happy to provide any additional details or debugging information, >> just let >> me know what you need. > > Can you attach a gdb backtrace taken during the hang? (thread apply all > backtrace full) I'll try and get these two completed over the weekend, at a minimum work on this Monday. Is there somewhere I can upload these logs to, where they won't go out to a public list? It's quite possible there might be information in here that we would prefer not go public. Thanks! Mark

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs