From: Sebastian Hagedorn (no email)
Date: Wed Feb 05 2003 - 08:04:38 EST
--On Saturday, February 01, 2003 16:34:51 -0500 Lawrence Greenfield
<leg+@andrew.cmu.edu> wrote:
> Probably grabbing the "strace" and a gdb backtrace of a "hung" imapd
> process would help figure out what they're waiting for. Might as well
> do master, too.
OK, I just recreated the situation. The imapd's all hang in a select()-call:
[root at lvr1 cyrus]# strace -p 19411
select(1, [0], NULL, NULL, {1729, 930000} <unfinished ...>
[root at lvr1 cyrus]# strace -p 19417
select(1, [0], NULL, NULL, {1716, 430000} <unfinished ...>
gdb backtraces look like this:
0x402e3bee in __select () from /lib/i686/libc.so.6
(gdb) bt
#0 0x402e3bee in __select () from /lib/i686/libc.so.6
#1 0x0811a994 in __DTOR_END__ ()
#2 0x0808410c in getword ()
#3 0x0804f37e in cmdloop ()
#4 0x0804efb2 in service_main ()
#5 0x0804d6a1 in main ()
#6 0x40218687 in __libc_start_main (main=0x804cd60 <main>, argc=1,
ubp_av=0xbffecdf4,
init=0x804b9e4 <_init>, fini=0x8098120 <_fini>, rtld_fini=0x4000dcd4
<_dl_fini>,
stack_end=0xbffecdec) at ../sysdeps/generic/libc-start.c:129
They seem to be the same for all of the processes ...
This is still cyrus-imapd 2.1.11. master still responds to POP requests, so
I don't think there's anything wrong with it.
Does this help in any way?
-- Sebastian Hagedorn M.A. - RZKR-R1 (Gebäude 52), Zi. 18, Robert-Koch-Str. 10 Zentrum für angewandte Informatik - Universitätsweiter Service RRZK Universität zu Köln / Cologne University - Tel. +49-221-478-5587
|
|
|