On Tue, Feb 14, 2006 at 03:19:23PM +0200, Timo Sirainen wrote:
Well, I noticed that at least the default dotlock timeout isn't necessarily big enough. You could see if just changing mbox_dotlock_change_timeout = 120 helps.
No, doesn't help. Can reproduce the problem just as easily after having set that. that.
Also I think I'll have to make Dovecot somehow touch the lock file once in a while so that if it's held for reading for a long time it's not overridden by other processes which think it's a stale lock file.
Would be good (although I'm not sure, how much time can a read normally take?). But this does not seem to be the problem here. It's short timeframes (less than 10 seconds), and Exim respects the locks for much longer.
Anyway one possible way to test locking is to set breakpoints into end of mbox_lock_dotlock() function and while it has stopped, run another process to see what it thinks of the dotlock.
I'm not sure what mean by running another process and seeing what it thinks of the dotlock (another IMAP process? how? what to check?), but I've set a break after the line confirming the dotlock:
mbox->mbox_dotlocked = TRUE;and at this point, a .lock file really exists. So at least the locking works, it appears also that dovecot properly takes care if it is already locked.
BTW. your hostnames aren't same in the different machines, right? And there's no other weirdness that prevents one process from seeing another? Because if Dovecot thinks that the process which has created the dotlock doesn't exist, it overrides the dotlock immediately.
No, there is nothing special of this kind. All hosts have unique hostnames, and all processes see all other processes on the server.
Dovecot and the MTA (Exim) delivery run on different hosts, though, but that is natural and shouldn't be a problem, right?
I will continue investigating, but I'm no longer sure it is locking related. Further advice is appreciated, of course.
Cheers, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.