On Tue, Jun 01, 2010 at 04:49:52PM -0400, Wesley Craig wrote:
> On 01 Jun 2010, at 14:05, Gary Mills wrote:
> > # pstack 12708
> > 12708: pop3d -s
> > feb1a5c5 read (0, 817faf0, b)
> > fec2dfaf sock_read () + 3f
> >
> >I don't know why the stack trace is so short with these.
>
> Thinking about this a little more...
>
> sock_read() is probably from openssl's BIO layer, and the stack trace
> is probably truncated because pstack can't follow the backtrace
> through the function pointer that SSL_read() is using to access
> sock_read(). This is an SSL connection, right? Take a look at the
> SSL_read() man page, for an idea of what can go wrong. Having
> written something very much like the prot suite for another project,
> I can say that SSL is really much happier with non-blocking IO, if
> you're hoping for control to return to the call at some point.
Yes, it's an SSL connection. It's possible that only POP3 connections
with SSL had the problem. I do notice some changes between
cyrus-imapd-2.3.8 and cyrus-imapd-2.3.16, in pop3d.c, that may be
relevant:
@@ -517,9 +541,10 @@
proc_register("pop3d", popd_clienthost, NULL, NULL);
/* Set inactivity timer */
- timeout = config_getint(IMAPOPT_POPTIMEOUT);
- if (timeout < 10) timeout = 10;
- prot_settimeout(popd_in, timeout*60);
+ popd_timeout = config_getint(IMAPOPT_POPTIMEOUT);
+ if (popd_timeout < 10) popd_timeout = 10;
+ popd_timeout *= 60;
+ prot_settimeout(popd_in, popd_timeout);
prot_setflushonread(popd_in, popd_out);
if (kflag) kpop();
@@ -1075,6 +1143,7 @@
result=tls_start_servertls(0, /* read */
1, /* write */
+ pop3s ? 180 : popd_timeout,
layerp,
&auth_id,
&tls_conn);
I wonder if an upgrade will solve this problem?
--
-Gary Mills- -Unix Group- -Computer and Network Services-
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
