openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 01 Dec '08

01 Dec '08

--On Friday, November 28, 2008 7:40 PM +0000 quanah(a)zimbra.com wrote: > > > --On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: Latest backtrace, with the patch from HEAD about idletimeout, we get: (gdb) bt #0 0x0000003fca02e21d in raise () from /lib64/tls/libc.so.6 #1 0x0000003fca02fa1e in abort () from /lib64/tls/libc.so.6 #2 0x0000003fca027ae1 in __assert_fail () from /lib64/tls/libc.so.6 #3 0x000000000042b5c1 in connection_close (c=0x3b69520) at connection.c:877 #4 0x0000000000429e7d in connections_timeout_idle (now=1228167365) at connection.c:242 #5 0x0000000000428097 in slapd_daemon_task (ptr=0x0) at daemon.c:2039 #6 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #8 0x0000000000000000 in ?? () Looking at the connection, we see: (gdb) frame 3 #3 0x000000000042b5c1 in connection_close (c=0x3b69520) at connection.c:877 877 connection.c: No such file or directory. in connection.c (gdb) print *c $1 = {c_struct_state = 2, c_conn_state = 3, c_conn_idx = 28, c_close_reason = 0x4bea5b "?", c_mutex = {__m_reserved = 2, __m_count = 0, __m_owner = 0x100002068, __m_kind = 0, __m_lock = { __status = 0, __spinlock = 0}}, c_sb = 0x13b4d860, c_starttime = 1228167365, c_activitytime = 1228167365, c_connid = 3120, c_peer_domain = {bv_len = 7, bv_val = 0xdfac1b0 "unknown"}, c_peer_name = {bv_len = 23, bv_val = 0x108dc558 "IP=192.168.58.225:53050"}, c_listener = 0x88df00, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = { sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x64abc00, stqh_last = 0x64abd58}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x3b69650}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 3556232921088, __spinlock = 414}, __c_waiting = 0x19e, __padding = "\236\001\000\000\000\000\000\0008\225ï¿½\003\000\000\000", __align = 0}, c_currentber = 0xe032000, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0xe035400, c_sasl_sockctx = 0x0, c_sasl_extra = 0x669cac8, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 1, c_n_ops_executing = 1, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 1, c_n_read = 1, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x43ea8c <slap_send_ldap_result>, c_send_search_entry = 0x43f787 <slap_send_search_entry>, c_send_search_reference = 0x44188d <slap_send_search_reference>, c_send_ldap_extended = 0x43f2fa <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x43f57e <slap_send_ldap_intermediate>} So this was file descriptor 28. This is definitely the same assert as before in connection.c: assert( c->c_conn_state == SLAP_C_CLOSING ); being line 877. Line 242 is: if( difftime( c->c_activitytime+global_idletimeout, now) < 0 ) { /* close it */ connection_closing( c, "idletimeout" ); --> connection_close( c ); i++; } The log file shows: Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: 28r Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:05 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:05 ldap slapd[8292]: Dec 2 03:06:05 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:05 ldap slapd[8292]: connection_closing: readying conn=3049 sd=28 for close Dec 2 03:06:05 ldap slapd[8292]: connection_resched: attempting closing conn=3049 sd=28 Dec 2 03:06:05 ldap slapd[8292]: daemon: removing 28 Dec 2 03:06:05 ldap slapd[8292]: conn=3049 fd=28 closed (idletimeout) Dec 2 03:06:05 ldap slapd[8292]: daemon: listen=7, new connection on 28 Dec 2 03:06:05 ldap slapd[8292]: daemon: added 28r (active) listener=(nil) Dec 2 03:06:05 ldap slapd[8292]: conn=3120 fd=28 ACCEPT from IP=192.168.58.225:53050 (IP=192.168.58.179:389) Dec 2 03:06:05 ldap slapd[8292]: conn=3120 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 And here's the start of the previous connection on descriptor 28: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: listen=7, new connection on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: added 28r (active) listener=(nil) Dec 2 03:03:53 ldap slapd[8292]: conn=3049 fd=28 ACCEPT from IP=192.168.61.35:57352 (IP=192.168.58.179:389) Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 2 descriptors Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=0 STARTTLS Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=0 RESULT oid= err=0 text= Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 RESULT tag=97 err=0 text= Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Then nothing logged again until the first segment quoted where it crashed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 01 Dec '08

01 Dec '08

Full_Name: Howard Allison Version: 2.4.11 OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.153.217.235) After running for a few hours slapd crashes and dumps core. here is the output from dbx: IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 with these flags: --prefix=/opt/pware/openldap-2.4.11 --with-openssl --with-shared=yes --enable-policy --enable-unique --enable-ssl Here is the slapd.conf file(DB part): database bdb suffix (excluded) rootdn (excluded) rootpw (excluded) index objectClass eq,pres index entryCSN,entryUUID eq index cn eq,sub index uid eq index memberUid eq index uidNumber eq index gidNumber eq directory /app/openldap/var/openldap-data/ checkpoint 1024 120 overlay syncprov syncprov-checkpoint 256 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_hash_cleartext Here is the output from ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited memory(kbytes) unlimited coredump(blocks) 2097151 nofiles(descriptors) 5000 threads(per process) unlimited processes(per user) unlimited

1 0

FW: (ITS#5832) Networking and Replication.
by Nils.Hammar＠cybercomgroup.com 30 Nov '08

30 Nov '08

------=_NextPart_000_0005_01C95387.D1D6DEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nils Hammar Direct / Mobile / SMS / MMS +46 733 12 34 63 Please remove the number 744 81 49 from your address book, it will be invalid after May 26, 2008. -----Original Message----- From: Nils Hammar Sent: den 28 november 2008 09:57 To: 'Quanah Gibson-Mount' Subject: RE: (ITS#5832) Networking and Replication. Oh - sorry, that was a reply to the wrong error, this commend should have been to #5831. /Nils Nils Hammar Direct / Mobile / SMS / MMS +46 733 12 34 63 Please remove the number 744 81 49 from your address book, it will be invalid after May 26, 2008. -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: den 28 november 2008 09:25 To: Nils Hammar; openldap-its(a)openldap.org Subject: RE: (ITS#5832) Networking and Replication. --On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. That makes no sense to me, BDB isn't communicating at the network level... Everything at that level is LDAP protocol. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------=_NextPart_000_0005_01C95387.D1D6DEA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZI AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2 YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8E KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHoweKFj pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/iKs s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEnw9G 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DWZj9 Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaMIIB HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UE CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEAxQL TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYVzyz IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4UbdPZT tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfMAkG A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZBJCs jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQesJ4 bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDOoYd N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smzKVM ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgxMjAxMDYzODM2WjAjBgkqhkiG9w0BCQQxFgQUxURdhNsEQuE10rmYAI4Q 40H7rcowZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYA5egAZCGPWaNZiOwYxxabYlhLwFxUlQTF3yznX XvQVMRiTt3XzlZwcZGoYQchD044ZU+ZmeWxABbn26OmKfEAtHrocVHxoWrdRqoVoRj0PmFtCUkGn kLT5USDAZFRT7DTh+cZTvTflP5XvSL3Zt08O3JAhcfD4AwYoCYwdxFF2WAAAAAAAAA== ------=_NextPart_000_0005_01C95387.D1D6DEA0--

1 0

Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it 30 Nov '08

30 Nov '08

quanah(a)zimbra.com wrote: > --On Saturday, November 29, 2008 5:32 AM +0000 manu(a)netbsd.org wrote: > >> Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: >> >>> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as >>> well. >> Did it? Where is the report about that? > > Can't find it atm, but I remember someone writing in about ACI's being > broken in HEAD right now, and I believe it was related to this change. > RE2.4 was a typo on my part, since this isn't in RE24 right now. Yes (I think it was Hallvard). ACIs broke since acl_string_expand() changed prototype, but the number of args was the same, and compiling succeeded with a warning (which I didn't notice, btw). To make it worse, test041 did not fail (apparently, it makes no use of string expansion). Now it's fixed; I'd say hacked, since I did not want to change the API of dynacl, yet. Changing the API should not be a big deal, given the presumably limited number of custom dynacl 'round. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5804) attribute value regex expantion
by quanah＠zimbra.com 29 Nov '08

29 Nov '08

--On Saturday, November 29, 2008 5:32 AM +0000 manu(a)netbsd.org wrote: > Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > >> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as >> well. > > Did it? Where is the report about that? Can't find it atm, but I remember someone writing in about ACI's being broken in HEAD right now, and I believe it was related to this change. RE2.4 was a typo on my part, since this isn't in RE24 right now. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 28 Nov '08

28 Nov '08

Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. Did it? Where is the report about that? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 29, 2008 1:33:51 AM +0000 quanah(a)OpenLDAP.org wrote: > > > --On November 28, 2008 11:37:25 PM +0000 quanah(a)OpenLDAP.org wrote: > > >> Patch from Howard needs to be expanded so that a new keyword is used for >> the idle timer here, rather than the value from idletimeout. This will >> require some reworking of the daemon to wake up for that interval as >> well. > > After this patch, slapd can stay up, but seems to not be able to shut > down. The threads show: Ok, it did eventually finish. After starting slapd again, however, I noticed: Nov 29 07:06:41 new slapd[26537]: conn=8 fd=31 ACCEPT from IP=192.168.61.21:36322 (`ï¿½) --Quanah

1 0

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 28, 2008 11:37:25 PM +0000 quanah(a)OpenLDAP.org wrote: > Patch from Howard needs to be expanded so that a new keyword is used for > the idle timer here, rather than the value from idletimeout. This will > require some reworking of the daemon to wake up for that interval as well. After this patch, slapd can stay up, but seems to not be able to shut down. The threads show: (gdb) thr apply all bt Thread 4 (Thread 1082132832 (LWP 2205)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8f58 in ldap_pvt_thread_cond_wait (cond=0x8a2f30, mutex=0x8a2f08) at thr_posix.c:299 #2 0x0000002a956c78e8 in ldap_pvt_thread_pool_destroy (tpool=0x617648, run_pending=1) at tpool.c:381 #3 0x0000000000429704 in slapd_daemon_task (ptr=0x0) at daemon.c:2516 #4 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #5 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #6 0x0000000000000000 in ?? () Thread 3 (Thread 1115703648 (LWP 2209)): #0 0x0000003fca90bd9c in __pread_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000002a97348edc in __os_io (dbenv=0xdc2100, op=1, fhp=0xf8d4d8, pgno=399474, pagesize=16384, buf=0x2ae8a1cc20 "Y,", niop=0x42681c30) at ../dist/../os/os_rw.c:55 #2 0x0000002a973405ea in __memp_pgread (dbmfp=0xeab3c0, mutexp=0x2bb963f008, bhp=0x2ae8a1cb88, can_create=0) at ../dist/../mp/mp_bh.c:219 #3 0x0000002a973413f7 in __memp_fget (dbmfp=0xeab3c0, pgnoaddr=0x42681d84, flags=0, addrp=0x42681d88) at ../dist/../mp/mp_fget.c:580 #4 0x0000002a972d18b3 in __bam_search (dbc=0xd2dc380, root_pgno=Variable "root_pgno" is not available. ) at ../dist/../btree/bt_search.c:307 #5 0x0000002a972c6e27 in __bam_c_search (dbc=0xd2dc380, root_pgno=0, key=0x42682050, flags=28, exactp=0x42681eb4) at ../dist/../btree/bt_cursor.c:2547 #6 0x0000002a972c7b7e in __bam_c_get (dbc=0xd2dc380, key=0x42682050, data=0x42682030, flags=28, pgnop=0x42681f24) at ../dist/../btree/bt_cursor.c:962 #7 0x0000002a9730f51b in __db_c_get (dbc_arg=0xd2dc1c0, key=0x42682050, data=0x42682030, flags=28) at ../dist/../db/db_cam.c:643 #8 0x0000002a973177d7 in __db_c_get_pp (dbc=0xd2dc1c0, key=0x42682050, data=0x42682030, flags=28) at ../dist/../db/db_iface.c:1836 #9 0x0000002a97184a16 in bdb_id2entry (be=0x42802a40, tid=0x0, locker=23, id=3443171, e=0x42682148) at id2entry.c:130 #10 0x0000002a97189e18 in bdb_cache_find_id (op=0x428025e0, tid=0x0, id=3443171, eip=0x42682310, islocked=0, locker=23, lock=0x42682250) at cache.c:714 #11 0x0000002a9717b1c7 in bdb_search (op=0x428025e0, rs=0x42802570) at search.c:696 #12 0x0000002a975921eb in syncprov_findcsn (op=0x5c1bc00, mode=FIND_PRESENT) at syncprov.c:681 #13 0x0000002a9759690a in syncprov_op_search (op=0x5c1bc00, rs=0x42803d60) at syncprov.c:2074 #14 0x000000000049b999 in overlay_op_walk (op=0x5c1bc00, rs=0x42803d60, which=op_search, oi=0xdec8c0, on=0xdec700) at backover.c:640 #15 0x000000000049bbf5 in over_op_func (op=0x5c1bc00, rs=0x42803d60, which=op_search) at backover.c:702 #16 0x000000000049bc8b in over_op_search (op=0x5c1bc00, rs=0x42803d60) at backover.c:724 #17 0x000000000042f23c in fe_op_search (op=0x5c1bc00, rs=0x42803d60) at search.c:355 #18 0x000000000042ed10 in do_search (op=0x5c1bc00, rs=0x42803d60) at search.c:217 #19 0x000000000042bdff in connection_operation (ctx=0x42803e90, arg_v=0x5c1bc00) at connection.c:1133 #20 0x000000000042c2ef in connection_read_thread (ctx=0x42803e90, argv=0x1e) at connection.c:1261 #21 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #22 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #23 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #24 0x0000000000000000 in ?? () Thread 2 (Thread 1124096352 (LWP 2210)): #0 bdb_idl_union (a=0xb3ff000, b=0xb1ff000) at idl.c:1151 #1 0x0000002a971829fc in inequality_candidates (op=0x5b11c00, ava=0x5a06518, ids=0xb3ff000, tmp=0xb1ff000, gtorlt=165) at filterindex.c:1063 #2 0x0000002a9717ff83 in bdb_filter_candidates (op=0x5b11c00, f=0x5a064f8, ids=0xb3ff000, tmp=0xb1ff000, stack=0xb4ff000) at filterindex.c:158 #3 0x0000002a97180595 in list_candidates (op=0x5b11c00, flist=0x5a064f8, ftype=160, ids=0xb2ff000, tmp=0xb1ff000, save=0xb3ff000) at filterindex.c:503 #4 0x0000002a97180213 in bdb_filter_candidates (op=0x5b11c00, f=0x5a064d8, ids=0xb2ff000, tmp=0xb1ff000, stack=0xb3ff000) at filterindex.c:183 #5 0x0000002a97180595 in list_candidates (op=0x5b11c00, flist=0x42e83670, ftype=160, ids=0x42f03970, tmp=0xb1ff000, save=0xb2ff000) at filterindex.c:503 #6 0x0000002a97180213 in bdb_filter_candidates (op=0x5b11c00, f=0x42e836d0, ids=0x42f03970, tmp=0xb1ff000, stack=0xb2ff000) at filterindex.c:183 #7 0x0000002a9717c2f1 in search_candidates (op=0x5b11c00, rs=0x43004d60, e=0x42e83910, locker=57, ids=0x42f03970, scopes=0x42e83970) at search.c:1124 #8 0x0000002a9717ad57 in bdb_search (op=0x5b11c00, rs=0x43004d60) at search.c:595 #9 0x000000000049ba2d in overlay_op_walk (op=0x5b11c00, rs=0x43004d60, which=op_search, oi=0xdece00, on=0x0) at backover.c:650 #10 0x000000000049bbf5 in over_op_func (op=0x5b11c00, rs=0x43004d60, which=op_search) at backover.c:702 #11 0x000000000049bc8b in over_op_search (op=0x5b11c00, rs=0x43004d60) at backover.c:724 #12 0x000000000042f23c in fe_op_search (op=0x5b11c00, rs=0x43004d60) at search.c:355 #13 0x000000000042ed10 in do_search (op=0x5b11c00, rs=0x43004d60) at search.c:217 #14 0x000000000042bdff in connection_operation (ctx=0x43004e90, arg_v=0x5b11c00) at connection.c:1133 #15 0x000000000042c2ef in connection_read_thread (ctx=0x43004e90, argv=0x19) at connection.c:1261 #16 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #17 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 1 (Thread 182904263232 (LWP 2201)): #0 0x0000003fca906ffb in pthread_join () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8eb0 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:193 #2 0x00000000004297d1 in slapd_daemon () at daemon.c:2581 #3 0x00000000004129d9 in main (argc=10, argv=0x7fbfffb918) at main.c:859 --Quanah

1 0

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 28, 2008 10:49:36 PM +0000 quanah(a)OpenLDAP.org wrote: > slapd ends up hanging indefinitely. This happened with 8 replicas > connected to the server, where for four of those replicas, the connection > between the master and the replica wouldn't connect (but you could go > from the replica to the master) at some point after the initial > connection was made. > > Patch to HEAD from Howard is committed. Patch from Howard needs to be expanded so that a new keyword is used for the idle timer here, rather than the value from idletimeout. This will require some reworking of the daemon to wake up for that interval as well. --Quanah

1 0

(ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24/RE23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a scenario where the network is broken (or other reasons, but that's where I hit it), slapd can get locked up waiting on writers to finish. When that happens, everything ends up in a pthread_cond_wait, like this: Thread 8 (Thread 1098918240 (LWP 18884)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8f58 in ldap_pvt_thread_cond_wait (cond=0x385bdf0, mutex=0x385bca0) at thr_posix.c:299 #2 0x000000000043dc91 in send_ldap_ber (conn=0x385bc88, ber=0x41680610) at result.c:198 #3 0x0000000000441450 in slap_send_search_entry (op=0x625bc00, rs=0x41801d60) at result.c:1137 #4 0x0000002a9717b9e1 in bdb_search (op=0x625bc00, rs=0x41801d60) at search.c:879 #5 0x000000000049b9c9 in overlay_op_walk (op=0x625bc00, rs=0x41801d60, which=op_search, oi=0xdece00, on=0x0) at backover.c:650 #6 0x000000000049bb91 in over_op_func (op=0x625bc00, rs=0x41801d60, which=op_search) at backover.c:702 #7 0x000000000049bc27 in over_op_search (op=0x625bc00, rs=0x41801d60) at backover.c:724 #8 0x000000000042f1d8 in fe_op_search (op=0x625bc00, rs=0x41801d60) at search.c:355 #9 0x000000000042ecac in do_search (op=0x625bc00, rs=0x41801d60) at search.c:217 #10 0x000000000042bd9c in connection_operation (ctx=0x41801e90, arg_v=0x625bc00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41801e90, argv=0x1f) at connection.c:1261 #12 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #13 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #14 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #15 0x0000000000000000 in ?? () slapd ends up hanging indefinitely. This happened with 8 replicas connected to the server, where for four of those replicas, the connection between the master and the replica wouldn't connect (but you could go from the replica to the master) at some point after the initial connection was made. Patch to HEAD from Howard is committed. --Quanah

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