[Dovecot] Timeouts connecting via POP3
I'm experiencing timeouts from time to time from both Mac Mail and Outlook when connecting to my server. I originally suspected that it might be process # related, so I increased the auth & login process counts but that hasn't seemed to make a difference.
I'm running 1.0rc10 which came with my DirectAdmin control panel. I'm wondering if this problem is known and was fixed in a later release? I'm waiting for instructions from the DirectAdmin folks on building a new version in case they do something special.
Any ideas?
Thanks!
On Wed, 2007-03-21 at 17:15 -0700, Don O'Neil wrote:
I'm experiencing timeouts from time to time from both Mac Mail and Outlook when connecting to my server. I originally suspected that it might be process # related, so I increased the auth & login process counts but that hasn't seemed to make a difference.
I'm running 1.0rc10 which came with my DirectAdmin control panel. I'm wondering if this problem is known and was fixed in a later release? I'm waiting for instructions from the DirectAdmin folks on building a new version in case they do something special.
Do you use SSL? It hangs before it can log in? What does Dovecot's logs show (set auth_verbose=yes)?
There's one bug related to that:
v1.0.rc15 2006-11-19 Timo Sirainen tss@iki.fi - Potential SSL hang fix at the beginning of the connection
And what do you use as passdb/userdb? Post the whole dovecot -n output?
I have SSL setup, but I'm not specifically using it myself when I get the hangs.... I'll have to set the log up and post the results next time it happens..
Here's the config output though:
# /etc/dovecot.conf protocols: imap imaps pop3 pop3s ssl_cert_file: /etc/exim.cert ssl_key_file: /etc/exim.key disable_plaintext_auth: 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_greeting: Dovecot DA ready. login_processes_count: 16 verbose_proctitle: yes mail_extra_groups: mail default_mail_env: maildir:~/Maildir umask: 7 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/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv auth default: username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@& count: 5 passdb: driver: passwd passdb: driver: passwd-file args: /etc/virtual/%d/passwd userdb: driver: passwd userdb: driver: passwd-file args: /etc/virtual/%d/passwd
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Wednesday, March 21, 2007 5:54 PM To: Don O'Neil Cc: dovecot@dovecot.org Subject: Re: [Dovecot] Timeouts connecting via POP3
On Wed, 2007-03-21 at 17:15 -0700, Don O'Neil wrote:
I'm experiencing timeouts from time to time from both Mac Mail and Outlook when connecting to my server. I originally suspected that it might be process # related, so I increased the auth & login process counts but that hasn't seemed to make a difference.
I'm running 1.0rc10 which came with my DirectAdmin control panel. I'm wondering if this problem is known and was fixed in a later release? I'm waiting for instructions from the DirectAdmin folks on building a new version in case they do something special.
Do you use SSL? It hangs before it can log in? What does Dovecot's logs show (set auth_verbose=yes)?
There's one bug related to that:
v1.0.rc15 2006-11-19 Timo Sirainen tss@iki.fi - Potential SSL hang fix at the beginning of the connection
And what do you use as passdb/userdb? Post the whole dovecot -n output?
On Wed, 2007-03-21 at 18:00 -0700, Don O'Neil wrote:
auth default: username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@& count: 5 passdb: driver: passwd passdb: driver: passwd-file args: /etc/virtual/%d/passwd userdb: driver: passwd userdb: driver: passwd-file args: /etc/virtual/%d/passwd
Where does passwd find the users? Are you using nss_ldap or something? Maybe the hangs are related to it? With newer Dovecot versions you can use blocking=yes setting, which does the passwd lookups in separate dovecot-auth worker processes, and if they use up all the processes it logs an error and returns "Internal error" to client instead of hanging.
Also if you have more virtual users than NSS users, it's faster to put the passwd-file passdb/userdb before the passwd, so that that the passwd-file lookups are done first.
Nope, not running nss_ldap... All of my users are virtual ones, so I've re-organized like you suggested.
Once I get the directions from the DA folks on updating I'll try the dovecot-auth blocking option if I still have the hanging.
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Wednesday, March 21, 2007 6:38 PM To: Don O'Neil Cc: 'Dovecot Mailing List' Subject: Re: [Dovecot] Timeouts connecting via POP3
On Wed, 2007-03-21 at 18:00 -0700, Don O'Neil wrote:
auth default: username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@& count: 5 passdb: driver: passwd passdb: driver: passwd-file args: /etc/virtual/%d/passwd userdb: driver: passwd userdb: driver: passwd-file args: /etc/virtual/%d/passwd
Where does passwd find the users? Are you using nss_ldap or something? Maybe the hangs are related to it? With newer Dovecot versions you can use blocking=yes setting, which does the passwd lookups in separate dovecot-auth worker processes, and if they use up all the processes it logs an error and returns "Internal error" to client instead of hanging.
Also if you have more virtual users than NSS users, it's faster to put the passwd-file passdb/userdb before the passwd, so that that the passwd-file lookups are done first.
Ok... It got stuck... Here is what was in the log:
Mar 21 20:00:28 kermit dovecot[25235]: pop3-login: Disconnected: Inactivity: rip=72.193.85.114, lip=64.69.41.217
When it works right, this is what is there:
Mar 21 20:04:42 kermit dovecot[34276]: pop3-login: Login: user=don@lizardhill.com, method=PLAIN, rip=72.193.85.114, lip=64.69.41.217 Mar 21 20:04:42 kermit dovecot[34276]: POP3(don@lizardhill.com): Disconnected: Logged out top=0/0, retr=0/0, del=0/175, size=4992146
Any clues from this? Could it be related to the DirectAdmin pop-before-smtp code? Or maybe stunnel? I haven't updated to the latest RC yet, so this may go away, but it's quite bothersome at the moment.
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Timo Sirainen Sent: Wednesday, March 21, 2007 6:38 PM To: Don O'Neil Cc: 'Dovecot Mailing List' Subject: Re: [Dovecot] Timeouts connecting via POP3
On Wed, 2007-03-21 at 18:00 -0700, Don O'Neil wrote:
auth default: username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@& count: 5 passdb: driver: passwd passdb: driver: passwd-file args: /etc/virtual/%d/passwd userdb: driver: passwd userdb: driver: passwd-file args: /etc/virtual/%d/passwd
Where does passwd find the users? Are you using nss_ldap or something? Maybe the hangs are related to it? With newer Dovecot versions you can use blocking=yes setting, which does the passwd lookups in separate dovecot-auth worker processes, and if they use up all the processes it logs an error and returns "Internal error" to client instead of hanging.
Also if you have more virtual users than NSS users, it's faster to put the passwd-file passdb/userdb before the passwd, so that that the passwd-file lookups are done first.
On 22.3.2007, at 5.08, Don O'Neil wrote:
Ok... It got stuck... Here is what was in the log:
Mar 21 20:00:28 kermit dovecot[25235]: pop3-login: Disconnected:
Inactivity: rip=72.193.85.114, lip=64.69.41.217
Well, this doesn't really tell anything. See http://dovecot.org/list/
dovecot/2007-March/020936.html for a similar problem. The first thing
in figuring out why it's broken is figuring out what exactly is
hanging..
participants (2)
-
Don O'Neil
-
Timo Sirainen