On 04 Jun 2010, at 12:23, Gary Mills wrote:
> I wonder if an upgrade will solve this problem?
Perhaps. The test accompanying that change suggests it might:
Prevented SSL_accept() from blocking indefinitely when using TLS/SSL
Of course, without a better backtrace, we don't know if you we
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.
>
>
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
On 01 Jun 2010, at 14:05, Gary Mills wrote:
> Yes, the timeout is set to zero in the pop3d.c file. However, the
> idle timeout actually works when I test it. In one window, I do this:
>
> $ telnet setup01 pop3
> Trying 130.179.16.64...
> Connected to setup01.cc.umanitoba.ca.
> Esc
On Fri, May 28, 2010 at 03:49:41PM -0400, Wesley Craig wrote:
> On 28 May 2010, at 12:42, Gary Mills wrote:
> > 0805e4ee proxy_check_input (815d168, 81a7228, 819e520, 81a3d60,
> >81a7700, 0) + 5e
>
> That last argument to proxy_check_input()? It's the timeout.
> Setting it to 0 means "don't
On 28 May 2010, at 12:42, Gary Mills wrote:
> 0805e4ee proxy_check_input (815d168, 81a7228, 819e520, 81a3d60,
> 81a7700, 0) + 5e
That last argument to proxy_check_input()? It's the timeout.
Setting it to 0 means "don't time out". I'm sure the theory is that
the underlying select() will r
On Thu, May 27, 2010 at 08:52:18PM -0400, Wesley Craig wrote:
>
> For your problem, pop3d calls:
>
> prot_settimeout(popd_in, popd_timeout);
>
> just below where you've inserted the KEEPALIVE. What do you have
> poptimeout set to?
It's set to 20 minutes.
> I wouldn't be surprised by a
Since you mention it...
I took a look at a random frontend, and found 27 or 33 pop processes
from two days ago. I used gdb to get stack traces from 3 samples,
all looked like this:
(gdb) where
#0 0x008007a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x008d6ff3 in __read_nocancel ()
