Cyrus 2.1.15 blocking connections after upgrade

Rob Siemborski rjs3 at
Mon Feb 9 10:49:22 EST 2004

On Mon, 9 Feb 2004, Mike Brodbelt wrote:

> I thought that master would always fork off an appropriate new process
> when it got a connection on any of the ports it was listening on.
> Obviously I've misunderstood something here - when an incoming
> connection is received on port 143, what should happen? My understanding
> was that master would hand the connection off to one of the service
> worker processes, and fork a new worker, so I thought that all
> connections should result in a fork.

Master and the service processes communicate over a socket -- master keeps
track of the number of available and busy workers, and when the available
number gets too low (below the "prefork" value) it starts a new one.  The
service processes themselves take care of answering the socket.

> > You should do a truss of an imapd as it gets a connection -- this might
> > give you more insight into what is going on.
> The server seems to currently be in a state where all incoming
> connections on port 143 connect, but hang until the network socket times
> out. Users who are already connected to running imapd processes have no
> problem whatsoever. I've appended a trace from a running imapd, where
> the user concerned checked the mailbox. I'm no expert on this level of
> tracing, but what it's doing looks reasonable to me:-

The key is what processes are listening to the socket (which shouldn't
drop to zero unless one of the above two conditions is true).  This issue
is fixed completely in the 2.2 branch.

Processes that are already connected won't show anything interesting.


Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

Home Page:
List Archives/Info:

More information about the Info-cyrus mailing list