Re: imapd and pop3d processes accumulate when clients disappear
On Mon, Jan 10, 2011 at 11:39:31PM +0100, Sebastian Hagedorn wrote: 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. Thanks for the information. So, a Cyrus or SASL upgrade some time in the future should fix this problem. I'm pleased that I won't need to carry my local fix forward to a new version. -- -Gary Mills--Unix Group--Computer and Network Services- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: imapd and pop3d processes accumulate when clients disappear
--On 11. Januar 2011 07:26:38 -0600 Gary Mills mi...@cc.umanitoba.ca wrote: On Mon, Jan 10, 2011 at 11:39:31PM +0100, Sebastian Hagedorn wrote: 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. Thanks for the information. So, a Cyrus or SASL upgrade some time in the future should fix this problem. I'm pleased that I won't need to carry my local fix forward to a new version. FWIW, I believe that the official fix works quite differently from yours. Yours enables TCP keepalives whereas the official one (introduced in 2.3.9, I believe) uses timeouts. I have no idea if one is superior to the other or what the ramifications are. All that matters to me is that it seems to be working :) -- .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:. p7s6CvSMyHRAI.p7s Description: S/MIME cryptographic signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
imapd and pop3d processes accumulate when clients disappear
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-nokeep Wed Apr 11 10:49:59 2007
+++ pop3d.c Mon May 17 18:17:22 2010
@@ -494,6 +494,12 @@
if (getsockname(0, (struct sockaddr *)popd_localaddr, salen) == 0) {
popd_haveaddr = 1;
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const void *)oval,
+sizeof(oval));
+ }
}
/* other params should be filled in */
--- imapd.c-nokeep Sun May 13 08:41:16 2007
+++ imapd.c Tue Jan 4 08:03:05 2011
@@ -786,6 +786,12 @@
imapd_haveaddr = 1;
}
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const void *)oval,
+sizeof(oval));
+ }
#ifdef DRAC_AUTH
if (((struct sockaddr *)imapd_remoteaddr)-sa_family == AF_INET)
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: imapd and pop3d processes accumulate when clients disappear
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 mi...@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/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
