[Dovecot] Problem in mbox-sync.c

[Hal Pomeranz]

> >Oct 21 19:36:01 postoffice1 dovecot: POP3(someuser): file mbox- 
> >sync.c: line 1433 (mbox_sync_handle_eof_updates): assertion failed:  
> >(file_size >= sync_ctx->expunged_space + trailer_size)
> 
> Does the file have CRLFs as linefeeds instead of plain LFs? CRLF  
> handling is probably still a bit buggy.

The mbox files are standard Unix text, so LF only, right?  We haven't
turned on the CRLF options in dovecot.conf, that's for sure.

> If that's not the problem then I'm not really sure.. It's difficult  
> to do anything about this unless I can reproduce the problem. I've  
> been using mboxes for my own mails fine for years. So if you can  
> figure out a way to easily reproduce this, I'd like to know.

We've done some more debugging since my original posting.  The way
to make the problem happen reliably seems to be to attempt to 
delete all messages from the mbox.  Thus, users who POP all their
mail off the server are affected, as are users who are using an
IMAP client to purge all their email from a given folder.  This problem
does not seem to be related to a specific email client, since we
can make the problem happen with different client programs.

But there must be some underlying problem with our setup somehow.
I can't believe that Dovecot's code for mailbox truncation is somehow
inherently flawed or some other site surely would have noticed this
problem before now.  A file system buffering issue?  I'm not sure.

I'm open to suggestions on this problem.  If anybody else can 
reproduce the issue, I'd be interested to hear about it, but in the
meantime I'm going to assume that something's hosed with our
specific configuration.

> >The real problem with this behavior is that sometimes, but not in all
> >cases, the process will leave behind a dotlock when it exits.  If the
> >abandoned dotlock is on the user's inbox, then procmail won't deliver
> >new mail to the user until the lock is cleared.  This is a big  
> >problem.
> 
> Dovecot writes the process's PID to the dotlock file. Procmail would  
> be able to check if the PID still exists and override the dotlock  
> immediately if it does. But since it doesn't do this, I guess you'd  
> have to modify its sources or create some wrapper script to delete  
> stale dotlocks.

Right.  We've been using the PIDs to manually decide which dotlocks
are stranded, but as you say getting procmail to do the right thing
would require source code hacks.  And the reality is that this wouldn't
fix the underlying issue, just sort of "paper over" the problem.
I'd prefer to fix the root cause.

-- 
Hal Pomeranz, Founder/CEO      Deer Run Associates      hal at deer-run.com
    Network Connectivity and Security, Systems Management, Training