Maybe too much of a good thing?

[Ken Murchison]

Sebastian Hagedorn wrote:
> Well,
> 
> the new patch works as intended (processes time out yet remain 
> straceable), but looks like it might be overzealous:
> 
> Nov 20 16:46:30 lvr13 pop3s[25622]: accepted connection
> Nov 20 16:46:30 lvr13 pop3s[25622]: error or timeout in SSL_accept() -> 
> done
> Nov 20 16:46:30 lvr13 pop3s[25622]: pop3s failed: ug-out-1314.google.com 
> [66.249.92.171]
> Nov 20 16:46:30 lvr13 pop3s[25622]: Fatal error: tls_start_servertls() 
> failed
> Nov 20 16:46:30 lvr13 master[32385]: process 25622 exited, status 75
> Nov 20 16:46:30 lvr13 master[32385]: service pop3s pid 25622 in BUSY 
> state: terminated abnormally
> 
> I understand that the timeout is not the only possible error condition, 
> but failing immediately seems strange. There are definitely more "error 
> or timeout in SSL_accept() -> done" messages than there used to be stuck 
> processes! Perhaps we should log the error code returned by 
> SSL_get_error()? I think I'll add some more logging locally.

OK, let me know what you find out.

I didn't change the logic if/when SSL_accept() fails, because if its an 
SSL_wrapped process, there is nothing to fall back on (the application 
protocol hasn't started yet).  Perhaps your dial-in clients take longer 
than 3 minutes to complete the handshake.

Hmm, from this particular log, I don't see the debug message tellinng us 
that we're waiting for more input.  When I test locally (over 
localhost), I always get at least in "-> waiting" log message before the 
"-> done" messsage.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University