Experiment to test TCP keepalive for pop3d proxies

[Gary Mills]

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-