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@deer-run.com Network Connectivity and Security, Systems Management, Training