imapd and pop3d processes accumulate when clients disappear

Sebastian Hagedorn Hagedorn at uni-koeln.de
Mon Jan 10 17:39:31 EST 2011


That was fixed quite a while ago ... we had the same problem, so I worked with one of the developers to debug and fix it.

Am 10.01.2011 um 23:23 schrieb Gary Mills <mills at cc.umanitoba.ca>:

> I've noticed on our murder front end that imapd and pop3d processes
> gradually accumulate.  Some of these can be several months old.  In
> both cases, the reason seems to be that the process is listening on
> standard input, but the client has disappeared.  Here's a typical
> stack trace:
> 
>    # pstack 5802
>    5802:      imapd -s
>     feb1a8f5 read     (0, 822dd48, 5)
>     fec2dfaf sock_read () + 3f
> 
> This only seems to happen when the client is using SSL or STARTTLS.
> The read() never times out.  Of course, restarting the Cyrus service
> does clean up these abandoned processes, but there should be a better
> way.  I've found that a simple modification to the daemons that
> enables TCP keepalives solves the problem.  We also shorten the
> keepalive interval with a global setting, but that shouldn't affect
> the results once the client has disappeared.
> 
> I'll attach the two patches.  They are for cyrus-imapd-2.3.8.  It
> would be better to have a Cyrus master option to enable these socket
> options, but these certainly work.
> 
> -- 
> -Gary Mills-        -Unix Group-        -Computer and Network Services-
> <pop3d.c.diff4>
> <imapd.c.diff4>
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/


More information about the Info-cyrus mailing list