imapd's hang when maxchild count is reached

[Scott Adkins]

I solved this problem a long time ago by passing an environment variable
from the master process to the child process when the child process is
spawned indicating that the server is full.  I used CYRUS_MAXCHILD, and
the child process already checks for the CYRUS_VERBOSE variable when it
starts in order to properly set the debugging level.  If that variable
was set, then the child would output an error message indicating that the
server was full and to try again later.  It would then close the client
connection and then exit.

A couple things to note:

  1) I prefer the client to be notified when the server is full and not
     simply get connection refused messages or have the email client just
     sit there, appearing to hang, while the server waits for a connection
     to become free.

  2) My method worked, but it didn't take advantage of the process reuse
     feature.  Basically, the master process only gets one chance to pass
     an environment variable off to the child process.  So, once that
     variable is set in the child, the child will always believe that the
     max has been reached.  That is why I had the child process go away,
     as it is basically useless after handling that one connection.

  3) If there was a good way for the master to notify the child process
     on each connection pass (either when passing the connection to an
     already available child, or when passing the connectioin to a newly
     spawn child) what the current status of maxchild is, then it would
     be quite efficient to send the server full messages, close the
     connection and wait for the master process to hand it another.  I
     don't know enough about how the master and child process communicate
     to know how to make this work.

Scott

--On Wednesday, February 05, 2003 12:57 PM -0500 Lawrence Greenfield 
<leg+ at andrew.cmu.edu> wrote:

>    Date: Wed, 05 Feb 2003 18:51:35 +0100
>    From: Sebastian Hagedorn <Hagedorn at uni-koeln.de>
> [...]
>    Wouldn't it be possible (and better) to refuse further connections
> instead     of having to wait for them to time out? Maybe I haven't
> thought this     through properly, but it seems to me as if that were
> cleaner.
>
> Yes, that would be desirable. The easiest way of doing this would be
> to close the socket used to accept() new connections. However, it's
> open in all of the children, so closing it is infeasible.
>
> The next option would be to have master accept() and then immediately
> close() the connection. This raises interesting blocking concerns and
> is thus somewhat harder to implement.
>
> Thus the current solution seems acceptable.
>
> Larry
>


-- 
 +-----------------------------------------------------------------------+
      Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
   UNIX Systems Engineer                  mailto:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20030205/e0c4cbc1/attachment.bin