openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: (ITS#5842) test049, test050 fail on Windows due to "con" filename
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 3:59 PM +0000 test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.11 / HEAD > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) > > > ``make test'' on Cygwin fails with test049, test050, because "con" is a > special device name on Windows. Thanks, fixed in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

02 Dec '08

--On Monday, December 01, 2008 9:51 PM +0000 quanah(a)zimbra.com wrote: > --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: As a side note, here's a working teardown: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: connection_closing: readying conn=52 sd=22 for close Dec 2 17:45:05 ldap slapd[29835]: connection_close: deferring conn=52 sd=-1 Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: connection_resched: attempting closing conn=52 sd=22 Dec 2 17:45:05 ldap slapd[29835]: daemon: removing 22 Dec 2 17:45:05 ldap slapd[29835]: conn=52 fd=22 closed (idletimeout) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 busy Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: listen=7, new connection on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: 22r Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: read active on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: added 22r (active) listener=(nil) Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: conn=63 fd=22 ACCEPT from IP=192.168.61.36:49196 (IP=192.168.58.179:389) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: As you can see, there's a break between the teardown and accept in this case, as compared to the scneario where it asserts. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5839) overlay glue
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 1:41 PM +0000 marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) The current OpenLDAP release is 2.4.13. The final OpenLDAP 2.3 release was 2.3.43. I suggest you try with either 2.3.43 if you don't want to move yet to OpenLDAP 2.4, or you switch to using OpenLDAP 2.4. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5842) test049, test050 fail on Windows due to "con" filename
by test.007＠seznam.cz 02 Dec '08

02 Dec '08

Full_Name: Test Seven Version: 2.4.11 / HEAD OS: Windows URL: Submission from: (NULL) (195.39.55.20) ``make test'' on Cygwin fails with test049, test050, because "con" is a special device name on Windows. Solution: simply use another name for consumer dir. --- test049-sync-config.orig Tue Feb 12 00:26:52 2008 +++ test049-sync-config Tue Dec 02 16:17:28 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons --- test050-syncrepl-multimaster.orig Mon May 05 23:42:54 2008 +++ test050-syncrepl-multimaster Tue Dec 02 16:25:52 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons

1 0

(ITS#5841) slapd hanging upon shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) After doing these two ldapmodify calls, shutting down slapd while the indexing task is running does not work anymore. slapd just keeps hanging. # ldapmodify -H ldapi:/// dn: olcDatabase={1}hdb,cn=config add: olcDbIndex olcDbIndex: cn eq,sub The above modification will trigger the indexing task. # ldapmodify -H ldapi:/// dn: cn=config replace: olcSizeLimit olcSizeLimit: 10000 When this operation is send while the indexing task is still running, it will wait for the task to complete. When slapd is shutdown during this timeframe, it will just lock up. Here is the backtrace of the hanging process: Thread 3 (Thread 0x7ff2ca2a5950 (LWP 13006)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f24fb in ldap_pvt_thread_pool_destroy (tpool=0x853688, run_pending=1) at ../../../libraries/libldap_r/tpool.c:570 pool = <value optimized out> pptr = (struct ldap_int_thread_pool_s *) 0x885540 task = <value optimized out> #2 0x0000000000431f9f in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2591 l = 2 last_idle_check = 0 ebadf = 0 #3 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ff2c9aa4950 (LWP 13007)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f2a4d in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at ../../../libraries/libldap_r/tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x885540 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x1c ctx = {ltu_id = 140680742193488, ltu_key = {{ltk_key = 0x4337e0, ltk_data = 0xb0ee20, ltk_free = 0x4338b0 <conn_counter_destroy>}, { ltk_key = 0x488c10, ltk_data = 0xb0ef30, ltk_free = 0x488710 <slap_sl_mem_destroy>}, {ltk_key = 0x4478f0, ltk_data = 0xb0e9d0, ltk_free = 0x4476d0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = <value optimized out> keyslot = 829 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #2 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ff2d0714710 (LWP 12992)): #0 0x00007ff2ce07c7b5 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042ee3c in slapd_daemon () at ../../../servers/slapd/daemon.c:2656 listener_tid = 140680750586192 rc = 0 #2 0x000000000041cd95 in main (argc=7, argv=0x7fffd874b9e8) at ../../../servers/slapd/main.c:948 i = <value optimized out> no_detach = 1 rc = -12 urls = 0x854030 "ldap:/// ldapi:///" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x0 configdir = 0x854010 "/etc/openldap/slapd.d" serverName = 0x7fffd874d63b "lt-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"

1 0

(ITS#5840) bdb_online_index and shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) When slapd is shutdown while the online indexing task is active it will stop the indexing task immediately leaving a half created index files behind. Searches that use the index afterwards will return imcomplete results. I wonder if we should wait for the indexing task to complete when shutting down the daemon or if there are any other ways to put the databases and the configuration back into a consistant state. (Apart from manually running slapindex)

1 0

(ITS#5839) overlay glue
by marin.lehouelleur＠astrium.eads.net 02 Dec '08

02 Dec '08

Full_Name: Marin Le Houelleur Version: 2.3.32 OS: Linux RH5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.94.82.30) Working for one year now with this version of Openldap. I come to the point I need to glue different branch of my master to the slaves to manage complexe filtering that I'm unable to manage with overlay syncrepl filters Master : 1 db database bdb suffix dc=exemple,dc=com It contains following ou's : sites, applis and orgz sites itselfs contains site1, site2... and may contain more which should not be replicated to other sites overlay synchrorepl Slaves (1 per site) : 2 dbs database bdb suffix ou=sites,dc=exemple,dc=com synchrepl rid=111 searchbase ou=sites,dc=exemple,dc=com filter="(ou:dn:=site1)" database bdb suffix dc=exemple,dc=com synchrepl rid=222 searchbase dc=exemple,dc=com filter="(|(ou:dn:=orgz)(ou:dn:=applis))" overlay glue glue-sub ou=sites,dc=exemple,dc=com @ slapd start the directive glue-sub is ignored I tried on the first db to had directive "subordinate advertise" instead but it's documented not to be needed when using glue overlay. Nevertheless the 1st db is synchronised and searchable but not visible in tools such as ldapbrowser. best regards,

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 02 Dec '08

02 Dec '08

It seems OK with 2.4.13 > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : mardi 18 novembre 2008 22:39 > À : Emmanuel Duru > Cc : 'Hallvard Breien Furuseth'; openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > Emmanuel Duru wrote: > > OK, my mistake, here follows a completely detailed description. > > I confirm HEAD and re24 behave as expected. > > 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#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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2008