[Dovecot] Intermittent timeout issues
Greetings list!
We've been experiencing an intermittent issue in which none users are able to log into the mail server for about 10 to 20 minutes.
This issue first appeared on our CentOS 4 box running dovecot 1.2.11 after upgrading from the stock version 0.99. The issue persists after migrating our users to a CentOS 5 server - also running version dovecot 1.2.11 but now in the 64-bit flavor.
Our users authenticate against LDAP via PAM in case that might be relevant.
I've yet to find anything "of interest" in the logs covering the outages. But here is what I've noticed:
- Users on our internal network are still able to authenticate and login.
- Users from the outside are "Disconnected for inactivity"
- Immediately after the restart, external users were able to log in again.
It almost sounds like the firewall is blocking external access except that:
- The version of dovecot was the thing that changed
- Everything starts working again after a dovecot restart
If anyone could provide some insight, I'd sure appreciate it.
Output of dovecot -n # 1.2.11: /etc/dovecot.conf # OS: Linux 2.6.18-164.15.1.el5 x86_64 CentOS release 5.4 (Final) listen: * shutdown_clients: no login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_process_per_connection: no login_trusted_networks: x.x.x.x/x login_max_processes_count: 164 max_mail_processes: 2048 mail_max_userip_connections: 50 mail_location: maildir:~/Maildir mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib64/dovecot/imap mail_plugin_dir(imap): /usr/lib64/dovecot/imap mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3 pop3_no_flag_updates(default): no pop3_no_flag_updates(imap): no pop3_no_flag_updates(pop3): yes pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh lda: postmaster_address: postmaster@domain.com sendmail_path: /usr/sbin/sendmail auth default: passdb: driver: pam userdb: driver: passwd
On Tue, Jun 1, 2010 at 12:58, Del Stoliker dstoliker@alphagraphics.com wrote:
It almost sounds like the firewall is blocking external access except that:
- The version of dovecot was the thing that changed
- Everything starts working again after a dovecot restart
It sounds like the firewall is doing something to the connections. I know that at least my IMAP client (Evolution) likes to hang on to an existing connection, even if nothing responds on the other end, for at least 15 minutes. By then the TCP layer drops it. For testing purposes, I've piped that connection coming from my desktop into a local port listened to by a program that relays all traffic to a connection it makes to the IMAP server. I can see it making requests and getting no answers if the server isn't responsive. If I kill that relay program, the client remakes the connection and all is well if a new connection can be established.
I have seen a related issue with another service which was due to the firewall shifting the TCP sequence numbers for security purposes, combined with routing asymmetry where return packets bypassed the firewall sometimes (the packets are discarded, rather than exposing an easy TCP takedown by forgery). In your case, outside users are the ones involved, so this scenario would only apply for you if there is a way for outsiders to get around the firewall.
Otherwise, your firewall may be losing connection state info and discarding further traffic without sending a TCP reset (usually they don't, but if you can configure it to do so, that can at least let new connections be made faster than the TCP stall timeout). Else, more memory or paid features or whatever for the firewall to hold more connection states. Or maybe it can be configured to pass all of this particular traffic without any TCP connection management features.
Look at TCP packets on each side of the firewall for the IMAP service and see if the sequence numbers or even source port numbers are different.
participants (2)
-
Del Stoliker
-
Phil Howard