On Tue, 10 Jul 2012, Kiss Gabor (Bitman) wrote:
#0 0xb7754424 in __kernel_vsyscall ()
#1 0xb720f96b in poll () from /lib/i686/cmov/libc.so.6
#2 0xb4d43444 in ldap_int_select (ld=0x91a8638, timeout=0x0) at os-ip.c:1098
#3 0xb4d2cdbb in wait4msg (ld=0x91a8638, msgid=4, all=0, timeout=0x0,
Actually I bet function wait4msg() in libraries/libldap/result.c
in OpenLDAP calls ldap_int_select() in endless loop with
zero timeout.
The strace output looked like there were pending events on fd 16 for the
select() call. In that case, it will return immediately...
Henrique,
I could create a core dump. Stack trace:
(gdb) bt
#0 0xb76f5424 in __kernel_vsyscall ()
#1 0xb71b096b in poll () from /lib/i686/cmov/libc.so.6
#2 0xb4ce in ldap_int_select () from /usr/lib/libldap_r-2.4.so.2
#3 0xb4ccddbb in ldap_result () from /usr/lib/libldap_r-2.4.so.2
#4 0xb4b1191e
Update:
According to wireshark no high volume network traffic occurs
during the rage. LDAP server runs Solaris, LDAP proxies are
not affected by leap second bug. So the problem seems to be local.
Gabor
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
#0 0xb76f5424 in __kernel_vsyscall ()
#1 0xb71b096b in poll () from /lib/i686/cmov/libc.so.6
#2 0xb4ce in ldap_int_select () from /usr/lib/libldap_r-2.4.so.2
#3 0xb4ccddbb in ldap_result () from /usr/lib/libldap_r-2.4.so.2
#4 0xb4b1191e in ?? () from /lib/libnss_ldap.so.2
#5
On Tue, 10 Jul 2012, Kiss Gabor (Bitman) wrote:
I could create a core dump. Stack trace:
(gdb) bt
#0 0xb76f5424 in __kernel_vsyscall ()
#1 0xb71b096b in poll () from /lib/i686/cmov/libc.so.6
#2 0xb4ce in ldap_int_select () from /usr/lib/libldap_r-2.4.so.2
#3 0xb4ccddbb in
Please confirm that this is not caused by the leap-second issues, i.e.
you've seen it on a freshely rebooted server, or prior to the 29th of
june.
Oooops!
I rebooted this morning, but wild imapd processes are raging again. :-(
Gabor
--
To UNSUBSCRIBE, email to
Package: cyrus-imapd-2.2
Version: 2.2.13-19+squeeze3
Severity: normal
I'm migrating some 40 IMAP users to a new server.
I found that imapd -s processes are proliferating and produce high load.
Strace shows that they call poll() continously:
12:40:01.934613 poll([{fd=16,
Please confirm that this is not caused by the leap-second issues, i.e.
you've seen it on a freshely rebooted server, or prior to the 29th of
june.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where
Please confirm that this is not caused by the leap-second issues, i.e.
you've seen it on a freshely rebooted server, or prior to the 29th of
june.
I can't.
Just a few hours ago I heard about first time about this kernel bug.
Like enough my problem is caused by it.
Thanks for your help.
Gabor
10 matches
Mail list logo
