[Dovecot] cannot update mailbox - unable to lock for exclusive access

[1st WebDesigns]

On 23/11/2012 06:07, Stan Hoeppner wrote:
> On 11/22/2012 3:26 PM, 1st WebDesigns wrote:
>> 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
>
> Are your mailboxes on NFS storage?  You haven't stated on what storage
> your mailboxes reside.  NFS complicates locking.  If you use an NFS
> server, did anything on it change recently, such as an upgrade to RHEL5?

No they are not on NFS storage, the mailboxes are stored on the local 
filesystem.

>
> I found a thread stating RHEL5 has a bad FCNTL implementation that could
> be related to your write lock delay problem.  Try using dotlock only for
> read and write and see if that helps.  It has additional filesystem IO
> overhead, but nothing like the many minutes of delay you have now.
>
> mbox_read_locks = dotlock
> mbox_write_locks = dotlock

Thank you I will try this.  I did read that when using Postfix and 
Dovecot, both systems should use a matching locking mechanism, which I 
had already tried.  However, I hadn't tried just dotlock, only FCNTL and 
a combination of FCNTL and dotlock.

>
>> We upgraded from RedHat 4 to RedHat 5.  The problem didn't exist with
>> RH4 and an even older version of Dovecot.
>
> That may be, but you're surely not planning on downgrading back to RHEL4.

No, not at all.

>
>> When emails are stuck in the queue, doing this:
>
> Dovecot doesn't use queues.  It writes directly to the mailbox files.
>
>> lsof /var/spool/mail/<user>
>
> These are mailbox files, your user inbox mbox files, not spool files.
> Spool implies temporary storage.  Don't let "spool" fool you.  On
> many/most systems /var/spool/mail is a link to /var/mail.

Yes that's correct.

>
>> 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.
>
> Does the larger timeout value completely eliminate the errors?  If so
> this may be the best outcome you can get with Dovecot 1.0.7, mbox
> storage, on RHEL5, unless a different locking method fixes it.

Yes it completely eliminates the errors.  If a pop3 connection has the 
lock, the mail simply sits there and is eventually delivered in (less 
than) 600 seconds.  Whereas before, it would get deferred.  When 
re-delivery was attempted, it's possible that the box would be locked 
again, and the mail would get deferred again, leading to a delay of 
several hours on a busy day.

>
>> 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).
>
> It's the version provided by RHEL5.  RHEL6.3 has Dovecot 2.0.9.  There
> are 3rd party 1.2.x RPMs available for RHEL5.x as well as 2.x.x RPMs for
> RHEL5.x.
>
> What "support company"?  If you're using RHEL, Red Hat provides the
> support.  That's the whole reason for "paying for" a Linux distro.  What
> is preventing you from upgrading to RHEL 6.3, the current release?
> Which BTW is behind nearly all other distros WRT package versions.  For
> instance Debian stable has Dovecot 2.1.7 available in the backports repo.

Our server is with Rackspace, and RHEL5 is the OS they offered us as an 
upgrade path from RHEL4.  So they're getting the support from Red Hat 
and we're getting the support from Rackspace.
>