On Tue, 2006-06-27 at 13:57 +0200, Thomas Hummel wrote:
On Tue, Jun 27, 2006 at 12:31:27PM +0300, Timo Sirainen wrote:
On Mon, 2006-06-26 at 18:03 +0200, Thomas Hummel wrote:
Hello,
"mbox_dotlock_change_timeout" directive :
a process seeing that an already locked (by another process) mbox he want to access hasn't change for this amount of time, allows himself to override the lock ?
Right. It checks that both the mbox and the dotlock file hasn't changed.
Thanks for your answers.
But still I don't get the use of overriding the dotlock since the other process that put that dotlock may well have fcntl'ed the mbox too (it could use a "dotlock + fcntl" exclusive locking method, just as dovecot does - it could be another dovecot mail process).
The idea is to override dotlock files that have been left around by proceses that have already died. They don't have fcntl locks or anything else. If Dovecot didn't ever override them, they'd just keep the mailbox locked until someone manually goes and deletes them.
So don't we risk to end up in a situation where the dotlock is ours but the mailbox is still fcntl-locked by another process ?
Actually not with Dovecot. When Dovecot is about to override the stale dotlock, it first tries to do the fcntl locking. If it succeeds, then the dotlock is overridden, if it doesn't succeed, then it fails with lock timeout. These checks have some race conditions so they're not perfect, but good enough to work practically always.