Cyrus 2.1.15 blocking connections after upgrade

Igor Brezac igor at
Mon Feb 9 11:37:30 EST 2004

On Mon, 9 Feb 2004, Mike Brodbelt wrote:

> Rob Siemborski wrote:
> > On Mon, 9 Feb 2004, Mike Brodbelt wrote:
> >
> > 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.
> Ah - OK, that definitely makes more sense. Looking at things, I also
> think you've pointed out where I've shot myself in the foot.....
> Looking at the processes with /var/lib/cyrus/socket/imap-0.lock open, I
> have 100 unique imapd processes running. A suspiciously round number, I
> thought. And looking in my cyrus.conf, I find:-
> imap            cmd="imapd -U 30" listen="imap" prefork=0 maxchild=100
> I will now go off and bang my head into a wall repeatedly, and remember
> to read config files installed from packages I didn't build myself with
> a more paranoid attitude next time....
> Thanks for helping me to get there...
> > 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.
> From interest, how can one easily identify processes that are awaiting a
> connection, as opposed to already connected child processes in an idle
> state, as both listen on the port, and show up with the socket open in
> an lsof?

Use trace/struss instead.  If the process is in accept(), it is awaiting
a connection.

Home Page:
List Archives/Info:

More information about the Info-cyrus mailing list