[Dovecot] Locking /var/mail/user issue with postfix and dovecot

[Ben Morrow]

At  1AM +0300 on 26/10/12 you (Robert JR) wrote:
> On 2012-10-26 00:15, Ben Morrow wrote:
> 
> > As Stan said earlier, this is a Postfix question. The rule for

[Looking back at the thread it wasn't Stan, it was Dennis Guhl. Sorry
about that.]

> > dotlocking is that you must create the .lock *before* opening the
> > file, in case whoever has it locked will be replacing the file
> > altogether; but with fcntl locking you must acquire the lock *after*
> > opening the file, since that's the way the syscall works. This means
> > that if Postfix is going to use both forms of lock, it has to
> > acquire a dotlock before it can look for a fcntl lock.
> >
> > In other words: the methods in mailbox_delivery_lock are *not* tried
> > in order, because they can't be. Dotlock is always tried first.
> >
> > You should have compatible locking settings for all your programs
> > accessing your mboxes. If Postfix is using dotlock, Dovecot should be
> > using dotlock as well. If you don't have any local programs (mail
> > clients, for instance) which require dotlocks, you should probably
> > change Postfix to just use fcntl locks.
>
> Thanks Ben for your valuable support and detailed explanation .. but 
> according to your explanation dovecot documentation contains wrong 
> explanation to the dotlock and that's why i was confused.
> 
> it is written as follow
> 
> **
> If multiple lock methods are used, which is usually the case since 
> dotlocks aren't typically used for read locking, the order in which the 
> locking is done is important. Consider if two programs were running at 
> the same time, both use dotlock and fcntl locking but in different 
> order:
> 
> Program A: fcntl locks the mbox
> Program B at the same time: dotlocks the mbox
> Program A continues: tries to dotlock the mbox, but since it's already 
> dotlocked by B, it starts waiting
> Program B continues: tries to fcntl lock the mbox, but since it's 
> already fcntl locked by A, it starts waiting
> Now both of them are waiting for each others locks. Finally after a 
> couple of minutes they time out and fail the operation.
> **
> 
> So this means that the documentation as mentioned above is wrong and 
> dotlock is always first even if the order is different ..

I just checked, and you are right: Dovecot *will* use the locking
strategies in the order listed. This is different from Postfix, which
*will not*, so the 'Postfix' section of the MboxLocking page on the wiki
is incorrect. 

For compatibility with Postfix, dotlock should always be listed first.

Note that you will still frequently see Postfix acquiring a dotlock but
then failing to acquire a fcntl lock. Dovecot's mbox_read_locks is
usually set to just 'fcntl', which means that when Dovecot has an mbox
open read-only it won't take a dotlock. This isn't really a problem,
assuming you don't use any programs locally which only take dotlocks;
but if that is the case you might as well configure everything to just
use fcntl locks, and forget dotlocks altogether.

Stan's earlier point is fundamentally correct: if you can treat the
Dovecot mailstore as a black box, with mail going in through the LDA and
LMTP and mail coming out through POP and IMAP, your life will be much
easier. Traditional Unix mailbox locking strategies are *completely*
insane, and if all you are doing is delivering mail from Postfix and
reading it from Dovecot it would be better to avoid them altogether, and
switch to dbox if you can. However, if you have any other programs which
touch the mail spool (local or NFS mail clients, deliveries through
procmail) this may not be possible.

Ben