Rob Mangiafico rmang@lexiconn.com wrote:
On Wed, 4 Feb 2009, Timo Sirainen wrote:
On Wed, 2009-02-04 at 11:17 -0700, Mark Costlow wrote:
Hello, I'm preparing to convert from qpopper + UW-IMAP to dovecot. So far testing has gone very well. One problem we haven't figured out is that long-running POP sessions keep the mailbox locked, so that the MDA times out while trying to deliver. ..
Switch to Maildir and the problem goes away.
We see this as well with mbox and pop3 accesses where some pop3 clients do not logout (iphone's are the worst offenders) for 30-90 minutes it seems. Timeout settings in dovecot.conf do not seem to help. procmail backs up waiting to get access to the inbox to deliver mail.
We are having the same problem. It's not a problem with imap, only with pop3. We're using deliver as the MDA. We're also using flock() locking for the mbox: is that what everyone else is using as well?
Migrating our servers to maildir globally is also not an option for us. In some cases, even convincing customers to use IMAP isn't going to work.
One problem which might be making this worse than it needs to be, is the fact that mbox_lock_flock in mbox-lock.c is not using a blocking flock(); instead, it's polling for a non-blocking lock. This technique can cause lock starvation, if another process is dropping the lock and picking it back up again frequently: other processes will only see the lock as being available if they happen to poll for the lock at just the right instant.
A better technique to use here, if it's adequately cross-platform, would be to set an alarm() for the max_wait_time, and use a blocking flock(). If the alarm times out and you don't have a lock, it's a timeout. In the meantime, you're guaranteed to eventually get the lock, if it is dropped.
That said: I'm not sure whether this will solve our problem in practice.
Why doesn't this happen with imap? Why can't we make pop3 do what imap does? Even if it's inefficient, it's better than hanging all incoming mail delivery while deliver eats up our local concurrency limits.
Thanks!
Alan Ferrency pair Networks, Inc. alan@pair.com