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 ---- 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
