openldap-bugs October 2007

openldap-bugs@openldap.org

38 participants
215 discussions

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by ando＠sys-net.it 03 Oct '07

03 Oct '07

pedrorandrade(a)gmail.com wrote: > Full_Name: Pedro RA > Version: 2.3.30-5 > OS: Debian 4.1.1-21 > URL: > Submission from: (NULL) (85.139.209.115) The latest release is 2.3.38. > When slapd is starting, and no database exists, slapd creates a new one with the > wrong permissions (user:root, group:root) > This probably is caused by slapd creating the database before chroot. Probably you mean before setuid(); chroot has nothing to do with the identity a process is running as. > The before-chroot creation of the database is the bug. The database is opened (and thus created, if it doesn't exist) only **after** setuid(). In fact, setuid() (and chroot() occur **before** even reading the configuration file. If it were like you say, the files would have been created **before** even knowing in which directory they should be located. > When this happens ldap-delete operations fail with: > ldap_delete: Internal (implementation specific) error (80) > additional info: entry index delete failed Probably you unintentionally performed some operation that created the files before starting slapd. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5166) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 03 Oct '07

03 Oct '07

Full_Name: Pedro RA Version: 2.3.30-5 OS: Debian 4.1.1-21 URL: Submission from: (NULL) (85.139.209.115) When slapd is starting, and no database exists, slapd creates a new one with the wrong permissions (user:root, group:root) This probably is caused by slapd creating the database before chroot. The before-chroot creation of the database is the bug. When this happens ldap-delete operations fail with: ldap_delete: Internal (implementation specific) error (80) additional info: entry index delete failed A working workaround is setting the right permissions to DBD files. In my system (Debian Etch 4.1.1-21, openldap 2.3.30-5) the command is: chmod -r openldap:openldap /var/lib/ldap

1 0

Issues with syncrepl and mirrormode
by Pierangelo Masarati 03 Oct '07

03 Oct '07

We're experiencing some strange issues with mirrormode; I don't have the whole picture at hand, right now, and I haven't been able to create the issue in a repeatable manner, however it happens regularly. The scenario is: 2 mirror-mode servers, each with 2 databases, plus back-config, replicated using syncrepl refreshAndPersist. We notice occasional sigsegv, and we could finally get a core dump, which contains #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 665 for (j=0; !BER_BVISNULL( &sc2->ctxcsn[j] ); j++) { (gdb) bt full #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 i = 0 j = 0 match = 0 text = 0x80e0e1a "\201� #1 0x080e7385 in do_syncrep2 (op=0x33a96d40, si=0x919c548) at ../../../servers/slapd/syncrepl.c:990 i = Variable "i" is not available. (gdb) p *sc1 $2 = {ctxcsn = 0x9981310, octet_str = {bv_len = 60, bv_val = 0x9d2b680 "rid=004,sid=000,csn=20070925132254.897919Z#000000#000#000000"}, rid = 4, sid = 0, numcsns = 1, sids = 0x9ce3120, sc_next = {stqe_next = 0x0}} (gdb) p *sc2 $3 = {ctxcsn = 0x0, octet_str = {bv_len = 20, bv_val = 0x9c299f0 "rid=004,sid=000,csn="}, rid = 4, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} p sc1->ctxcsn[0] $4 = {bv_len = 40, bv_val = 0x9e98cf0 "20070925132254.897919Z#000000#000#000000"} (gdb) p sc1->ctxcsn[1] $5 = {bv_len = 0, bv_val = 0x0} (gdb) p sc1->sids[0] $6 = 0 (gdb) p sc1->sids[1] $7 = 159661424 (gdb) p sc2->ctxcsn[0] $8 = {bv_len = 0, bv_val = 0x0} (gdb) p sc2->sids[0] $9 = 0 Line numbers may be slightly off because of minimal customization which should not impact this functionality. Mi first question is: is "rid=004,sid=000,csn=" a legitimate cookie? If it is, the code must account for (not) calling compare_csns() when the ctxcsn member of either struct sync_cookie is NULL. In that case, I suggest the patch Index: servers/slapd/syncrepl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v retrieving revision 1.361 diff -u -r1.361 syncrepl.c --- servers/slapd/syncrepl.c 29 Sep 2007 14:11:28 -0000 1.361 +++ servers/slapd/syncrepl.c 1 Oct 2007 12:25:05 -0000 @@ -985,7 +985,13 @@ if ( !BER_BVISNULL( &syncCookie.octet_str ) ) { slap_parse_sync_cookie( &syncCookie, NULL ); - compare_csns( &syncCookie_req, &syncCookie, &m ); + m = 0; + if ( syncCookie.ctxcsn ) { + compare_csns( &syncCookie_req, &syncCookie, &m ); + } else { + /* otherwise it would be dereferenced few lines below */ + assert( !refreshDeletes ); + } } } if ( ber_peek_tag( ber, &len ) == So the second question, assuming the above cookie is legitimate, would be: is it legitimate that the above cookie will only occur with refreshDelete unset? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 16

Re: (ITS#5162) Bus Error - core dumped
by hyc＠symas.com 03 Oct '07

03 Oct '07

piotr.tarnowski(a)us.edu.pl wrote: > Full_Name: Piotr Tarnowski (DrFugazi) > Version: 2.3.38 > OS: Solaris 10 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.158.96.61) > > > Hello, > > I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) > system. > I tried many times with many compilation options, but I still have an error with > 'gmake test': > >>>>>> Starting test001-slapadd ... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve all the entries... > Waiting 5 seconds for slapd to start... > 4378 Bus Error - core dumped > Waiting 5 seconds for slapd to start... Please read the FAQ http://www.openldap.org/faq/index.cgi?file=59 for information on how to obtain a trace. -- -- Howard Chu Chief Architect, 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#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On October 2, 2007 10:20:45 PM +0000 quanah(a)zimbra.com wrote: > <http://bugzilla.zimbra.com/attachment.cgi?id=5896> Here's the full output, so one doesn't need to sign up to bugzilla to view it. Thread 26 (Thread 1082132832 (LWP 3925)): #0 0x0000003fca0c6c9c in epoll_wait () from /lib64/tls/libc.so.6 #1 0x000000000041c2fe in slapd_daemon_task () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 25 (Thread 1090525536 (LWP 3926)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 24 (Thread 1098918240 (LWP 3927)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x000000000042b951 in send_ldap_ber () #2 0x000000000042e961 in slap_send_search_entry () #3 0x00000000004cbdd1 in syncprov_qtask () #4 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #5 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #6 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #7 0x0000000000000000 in ?? () Thread 23 (Thread 1107310944 (LWP 3928)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x00000000420017e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000420017c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 22 (Thread 1115703648 (LWP 3929)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x0000000042803a00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000428039e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 21 (Thread 1124096352 (LWP 3930)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 20 (Thread 1132489056 (LWP 3931)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 19 (Thread 1140881760 (LWP 3932)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x0000000044006a00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000440069e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 18 (Thread 1149274464 (LWP 4038)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 17 (Thread 1157667168 (LWP 4039)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x00000000450087c0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047a98e in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000450087a0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000424528 in fe_op_add () #12 0x0000000000424f5a in do_add () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 16 (Thread 1166059872 (LWP 4056)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 15 (Thread 1174452576 (LWP 4061)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004600a7c0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047a98e in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004600a7a0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000424528 in fe_op_add () #12 0x0000000000424f5a in do_add () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 14 (Thread 1182845280 (LWP 4316)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 1191237984 (LWP 4317)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 12 (Thread 1199630688 (LWP 10576)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004780da00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004780d9e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 11 (Thread 1208023392 (LWP 10593)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 10 (Thread 1216416096 (LWP 10602)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 1224808800 (LWP 10603)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 8 (Thread 1233201504 (LWP 13176)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 7 (Thread 1241594208 (LWP 13177)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 1249986912 (LWP 13178)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 1258379616 (LWP 13179)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (Thread 1266772320 (LWP 13180)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004b8147e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004b8147c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 3 (Thread 1275165024 (LWP 13230)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004c0157e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004c0157c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 2 (Thread 1283557728 (LWP 13553)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 182897791712 (LWP 3835)): #0 0x0000003fca906ffb in pthread_join () from /lib64/tls/libpthread.so.0 #1 0x000000000041cca1 in slapd_daemon () #2 0x000000000040d139 in main () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On October 2, 2007 10:20:45 PM +0000 quanah(a)zimbra.com wrote: >> This has nothing to do with BDB so db_stat isn't relevant here. It's >> about the accesslog overlay and any other overlays that may be >> manipulating the callback stack, so your slapd.conf is more relevant >> here. > Here's the slapd.conf (comments stripped): include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/openldap/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/openldap/schema/zimbra.schema" include "/opt/zimbra/lib/conf/zimbra-ext.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" TLSCertificateFile /opt/zimbra/conf/slapd.crt TLSCertificateKeyFile /opt/zimbra/conf/slapd.key TLSVerifyClient never access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,objectclass,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumb er,title,uid by dn.children="cn=admins,cn=zimbra" write by * read access to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryA ddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read database config rootpw {SSHA}XXXX database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read database bdb suffix cn=accesslog directory /opt/zimbra/openldap-data/accesslog/db rootdn cn=accesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read dbconfig set_cachesize 0 629145600 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /opt/zimbra/openldap-data/accesslog/logs dbconfig set_flags DB_LOG_AUTOREMOVE checkpoint 1024 5 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" rootpw {SSHA}XXXXXXX cachesize 300000 checkpoint 64 5 loglevel 256 threads 16 idlcachesize 300000 directory "/opt/zimbra/openldap-data" index objectClass eq index zimbraForeignPrincipal eq index zimbraId eq index zimbraVirtualHostname eq index zimbraMailCatchAllAddress eq,sub index zimbraMailDeliveryAddress eq,sub index zimbraMailForwardingAddress eq index zimbraMailAlias eq,sub index zimbraDomainName eq,sub index zimbraShareInfo sub index uid pres,eq index mail pres,eq,sub index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub index zimbraCalResSite eq,sub index zimbraCalResBuilding eq,sub index zimbraCalResFloor eq,sub index zimbraCalResRoom eq,sub index zimbraCalResCapacity eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 04+00:00 01+00:00 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On October 2, 2007 8:26:10 PM +0000 hyc(a)symas.com wrote: > Based on the (unreliable) pstack output it appears that all of the > threads are waiting for the same mutex. This of course shouldn't be > possible since one of those threads must already own it. We really need > to have gdb access here to inspect the state of the mutex and see which > thread is the owner, then figure out why it's trying to lock it again. > In OpenLDAP 2.3 this pretty much means that some operation locked the > mutex and somehow completed without unlocking it, i.e. completed without > going thru the accesslog response callback. > > This has nothing to do with BDB so db_stat isn't relevant here. It's > about the accesslog overlay and any other overlays that may be > manipulating the callback stack, so your slapd.conf is more relevant > here. I mainly wanted the db_stat information to make sure there were no held writelocks, which it is clear is not the case. I find I do have another pstack output from this same type of hang with another client at: <http://bugzilla.zimbra.com/attachment.cgi?id=5896> I'm working on getting the slapd.conf in question, but I believe the only overlays affecting the BDB backend are syncprov and accesslog. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5165) strtoul(3) might be used incorrectly
by ando＠sys-net.it 02 Oct '07

02 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Occasionally, strtoul(3) is used in slapd(8) to parse integers that are expected to be unsigned. It seems that strtoul(3) is used under the assumption that it will fail if a negative number is encountered. This is not the case; in fact, by design, negative numbers are read as positive, and negated. If negative numbers are not allowed, strtol(3) should be used instead, and the value should be checked (or the string should be checked for '-' before calling strtoul(3). p.

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by hyc＠symas.com 02 Oct '07

02 Oct '07

quanah(a)zimbra.com wrote: > --On Tuesday, October 02, 2007 3:28 AM +0000 quanah(a)zimbra.com wrote: > >> --On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: >> >>> quanah(a)zimbra.com wrote: >>>> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >>>> >>>>> The following files will be uploaded to the ftp site, where # will be >>>>> the assigned ITS number. >>>> URL's specifically are: >>>> >>>> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >>>> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >>>> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> >>> The pstack output is a bit odd, is this a regular debug build? With frame >>> pointers, etc? Can you get a stack trace in gdb? >> It is a regular build, and they killed and restarted it before getting >> any gdb information. We've asked them to please get the gdb information >> in the future. Since it has happened twice now for thi particular group >> in about a month, I'm hopeful it'll happen again before too long. ;) > > And here is the last logged operation: > > Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD > dn="uid=XXXXXXX,ou=people,dc=YYYYYY,dc=com" > Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD > attr=zimbraLastLogonTimestamp Based on the (unreliable) pstack output it appears that all of the threads are waiting for the same mutex. This of course shouldn't be possible since one of those threads must already own it. We really need to have gdb access here to inspect the state of the mutex and see which thread is the owner, then figure out why it's trying to lock it again. In OpenLDAP 2.3 this pretty much means that some operation locked the mutex and somehow completed without unlocking it, i.e. completed without going thru the accesslog response callback. This has nothing to do with BDB so db_stat isn't relevant here. It's about the accesslog overlay and any other overlays that may be manipulating the callback stack, so your slapd.conf is more relevant here. -- -- Howard Chu Chief Architect, 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#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On Tuesday, October 02, 2007 3:28 AM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: > >> quanah(a)zimbra.com wrote: >>> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >>> >>>> The following files will be uploaded to the ftp site, where # will be >>>> the assigned ITS number. >>> >>> URL's specifically are: >>> >>> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >>> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >>> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> >> >> The pstack output is a bit odd, is this a regular debug build? With frame >> pointers, etc? Can you get a stack trace in gdb? > > It is a regular build, and they killed and restarted it before getting > any gdb information. We've asked them to please get the gdb information > in the future. Since it has happened twice now for thi particular group > in about a month, I'm hopeful it'll happen again before too long. ;) And here is the last logged operation: Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD dn="uid=XXXXXXX,ou=people,dc=YYYYYY,dc=com" Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD attr=zimbraLastLogonTimestamp Then it just hung. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2007