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) ?
- 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@pasteur.fr | Pôle informatique - systèmes et réseau