From: Lawrence Greenfield (leg plus at andrew dot cmu dot edu)
Date: Sat Feb 01 2003 - 16:34:51 EST
Date: Fri, 31 Jan 2003 23:25:29 +0100
From: Sebastian Hagedorn <>
[...]
When the number of impad processes reaches 200, no more processes are
spawned, just as it should be. However, sometimes, not immediately, but
definitely after a while *all* imapd processes will hang if we try to open
more connections to port 143. This is 100% reproducible. If we kill one of
the scripts and the number of processes goes down, all the imapd's get
unstuck, but not until that happens.
What do you mean by "hang"? Do they actually stop answering their
current IMAP commands? Do they stop answering new connections when
their current one goes away?
I've checked the archives but haven't seen mention of this problem. Is this
a known issue? Is there a workaround?
I don't see any particular reason for (either) phenomenon making a quick
gaze at the code.
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.
Larry
|
|
|