[Dovecot] mbox locking

[Thomas Hummel]

On Wed, Jun 28, 2006 at 12:30:06AM +0300, Timo Sirainen wrote:

> I don't think D means dead even in BSDs? Usually it means
> non-interruptible sleep in kernel. 

Actually, you're right :

"D       Marks a process in disk (or other short term, uninter-
        ruptible) wait."

> I think it could mean that there's a
> deadlock between processes (due to different lock ordering). 

I don't think that's the case since in my case only procmail normaly
writes into the mbox and the lock method ordering is the same as in
dovecot. Maybe some user write directy via some UA like pine, elm or
mutt though.


> If there's only one process for the user in that state it means the
> kernel is broken. If you're using NFS it probably means your lockd
> got broken.

I should investigate this indeed.

> Because often Dovecot is the only one reading the mboxes, but there may
> be multiple different mail delivery agents each using their own locking
> scheme, but pretty much all of them use dotlock.

I see. In my situation, I cannot be sure that dovecot is the only one
which reads.

> If a mail delivery agent uses only dotlocking, then it means that
> Dovecot's read locking doesn't work, so Dovecot could see half-written
> mails at the end of the mbox. 

In such a case, does it get corrected on the next mbox read or is it
too late (the UA as already seen/cached the half written message) ?


> > 2. Obviously, fcntl in write_locks should be exclusive, but is the
> > lock set by fcntl in mbox_read_lock exclusive or shared ?
> 
> It's shared.

> Writers should do also the fcntl locking. As long as that's done,
> multiple shared fcntl locks can be acquired so it's then safe to read
> the mbox.

So you seem to confirm that a read should acutally block a write (note
: this seem to make sense but I was wondering if some priority to
writes were not implemented) ?

Thanks.

-- 
Thomas Hummel 	    | Institut Pasteur
<hummel at pasteur.fr> | Pôle informatique - systèmes et réseau