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@xxxxxxxxxxxxxxx>: > 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/ ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
