[Dovecot] Re: New mail sometimes fails to appear

[Timo Sirainen]

On Tue, 2006-02-14 at 11:40 +0200, Tom Alsberg wrote:
> On Tue, Feb 14, 2006 at 10:59:49AM +0200, Timo Sirainen wrote:
> > >    Attached is an example of one such last message saved from
> > >    Thunderbird after new mail arrived that was not seen.  The filler
> > >    characters are bytes of 0x80, and then the next message from
> > >    "n-Path: " is present.
> > 
> > They're actually 0x00 inside the mbox file, but Dovecot just translates
> > them to 0x80 since IMAP doesn't allow sending 0x00 characters.
> 
> Oh, I see...
> 
> BTW, why 0x80, of all characters?

Just copying UW-IMAP's behavior.

> > I don't remember having tested mbox_read_locks=dotlock, but I'd have
> > thought it would have worked..
> 
> I'll try to investigate more soon.  If you can provide some ideas on
> how to check the locking it could help (given that Dovecot locks for a
> short period of time only, I can't easily fabricate concurrent locking
> from outside, and it appears just holding a read lock all the time
> will not do much).

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.

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.

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.

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.