[Dovecot] SSL connections frozen on Dovecot 1.0.0
Hello,
We are running Dovecot 1.0.0 (Debian Etch, Backports.org, OpenSSL) in a production environment and we experience sporadic SSL connection problems. At the moment, it's difficult to tell if the server goes back to normal operation after some time or if it can be reproduces at any time because we have to restart it as soon as we get Nagios alerts.
Some tests with openssl s_client have shown difficulties to proceed the SSL handshake (hanging at different stages), or no response to IMAP commands.
SSL client used: openssl s_client -host imap -port 993
- First case : s_client hangs on the first output "CONNECTED(00000003)" and there is no handshake at all;
- Second case : like the first but the handshake starts after a few minutes;
- Third case : the handshake goes fine but the "OK" server banner is never sent (no response to commands);
- Fourth case : the greeting banner is received but dovecot will never answer.
The configuration file is almost identical to the default and SSL certificate is not the autogenerated one. Log files do not show dying process.
I've searched the ML archive for SSL issues but not found related bug. Does anyone use the Backport.org package of Dovecot ?
Thank you :)
-- Thibault VINCENT tibal@reloaded.fr thibault.vincent@reloaded.fr PGP Key : 0x4BA8A39B
On Thu, 2007-08-23 at 14:24 +0200, Thibault VINCENT wrote:
- First case : s_client hangs on the first output "CONNECTED(00000003)" and there is no handshake at all;
- Second case : like the first but the handshake starts after a few minutes;
- Third case : the handshake goes fine but the "OK" server banner is never sent (no response to commands);
- Fourth case : the greeting banner is received but dovecot will never answer.
The configuration file is almost identical to the default and SSL certificate is not the autogenerated one. Log files do not show dying process.
You could strace imap-login process to see what it's doing while the connection is hanging, and what changes when the handshake starts. Set login_processes_count=1 to make it easier to figure out what imap-login process to strace.
Timo Sirainen a écrit :
You could strace imap-login process to see what it's doing while the connection is hanging, and what changes when the handshake starts. Set login_processes_count=1 to make it easier to figure out what imap-login process to strace. Thank you Timo, but how can I figure out what imap-login process needs to be straced with login_processes_count=1 ? Even with this setting, I have about 60 imap-login processes and it's impossible to pick the right one (if I was able to login, I could actually find it with the PPID of it's child but I can't). I've enabled plain IMAP so next time it crashes I'll see if only the SSL sessions are affected.
-- Thibault VINCENT
On Mon, 2007-08-27 at 16:21 +0200, Thibault VINCENT wrote:
Timo Sirainen a écrit :
You could strace imap-login process to see what it's doing while the connection is hanging, and what changes when the handshake starts. Set login_processes_count=1 to make it easier to figure out what imap-login process to strace. Thank you Timo, but how can I figure out what imap-login process needs to be straced with login_processes_count=1 ? Even with this setting, I have about 60 imap-login processes and it's impossible to pick the right one (if I was able to login, I could actually find it with the PPID of it's child but I can't). I've enabled plain IMAP so next time it crashes I'll see if only the SSL sessions are affected.
I thought that you'd be running with only a single user testing it. If you've 60 users logged in at the same time it's pretty difficult to figure out what's hanging.
You could run another Dovecot instance in a different port and have that one user use a different port. Then you'd be able to find the login process more easily (e.g. netstat -lnp). Running another instance is explained in http://wiki.dovecot.org/RunningDovecot
participants (2)
-
Thibault VINCENT
-
Timo Sirainen