imapd's hang when maxchild count is reached

Lawrence Greenfield leg+ at andrew.cmu.edu
Sat Feb 1 16:34:51 EST 2003


   Date: Fri, 31 Jan 2003 23:25:29 +0100
   From: Sebastian Hagedorn <Hagedorn at uni-koeln.de>
[...]
   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





More information about the Info-cyrus mailing list