Output of dovecot -n is as follows:
# 1.0.7: /etc/dovecot.conf
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
mail_privileged_group: mail
mail_location: mbox:~/mail:INBOX=/var/mail/%u
mbox_lock_timeout: 600
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
auth default:
passdb:
driver: pam
userdb:
driver: passwd
We upgraded from RedHat 4 to RedHat 5. The problem didn't exist with
RH4 and an even older version of Dovecot.
When emails are stuck in the queue, doing this:
lsof /var/spool/mail/<user>
shows the spool file in use by a pop3 login and the Dovecot deliver
process. Since changing mbox_lock_timeout from 300 to 600 the pop3
process eventually finishes before 600 seconds and the deliver process
is able to complete. I admit this is masking the problem rather than
solving it.
As discussed before our version of Dovecot is dated now, however it's
the version provided by RedHat and the version supported by our support
company (who aren't doing a great job, hence me posting here).
Thanks,
On 22/11/2012 12:09, Stan Hoeppner wrote:
On 11/12/2012 5:15 AM, 1st WebDesigns wrote:
Thanks for your replies. I switched to Dovecot LDA this morning, but
the issue still persists, albeit logged slightly differently by Dovecot
now instead of Postfix:
"save failed to INBOX: Timeout while waiting for lock"
The reason is because some pop3 clients
Full stop. This is the first time you've mentioned POP that I recall.
FYI, Dovecot is primarily an IMAP server. Unless an OP states up front
that he's using primarily POP, everyone assumes IMAP and counsels
accordingly. You should have stated POP in your first post. Actually,
you should have included many more details prior to now. Please post
your complete 'dovecot -n' output.
are holding their connection for
5 or 6 minutes (don't ask me why - and the iPhone seems to be the major
culprit).
I'm no smartphone POP expert, but old rural tower, poor tower
connection, etc, all cause low data rates, which could cause this.
However, you state this problem cropped up out of nowhere after a distro
upgrade to CentOS 5. Can you confirm that the problem didn't exist
before the upgrade? Your definitive answer to this question dictates
the troubleshooting course of action.
In dovecot.conf I changed:
mbox_lock_timeout = 300
to
mbox_lock_timeout = 600
Which seems to have helped. I am unclear if this value only applied to
Dovecot LDA or if it would have worked previously before switching to
Dovecot LDA?
This simply changes how long Dovecot will wait to acquire a lock.
Increasing this value simply increases delays, masks the underlying
problem without really helping much.
The only real architectural solution to such a POP/mbox locking problem
due to slow/long client downloads is, as you mentioned, moving to a
lockless mailbox format, such as maildir or sdbox.
Worth noting, we are both/all at fault in the slow progress of this
issue, you for not stating POP up front, and me/us for not asking.
Your 'dovecot -n' output may allow us to help get mbox working a little
better, but the long term solution is very likely moving to maildir/sdbox.
