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