On Sun, 2007-05-13 at 22:10 +0200, Jan-Frode Myklebust wrote:
On Sun, May 13, 2007 at 08:50:16PM +0300, Timo Sirainen wrote:
Was it courier-dovecot-migrate.pl then that created those broken uidlist files?
Yes, we cleaned these up manually.
OK, updated the script so other people won't run into the same problem.
deliver(xxxxx@xxxxx): file mail-index-sync-update.c: line 841 (mail_index_sync_update_index): assertion failed: (view->hdr.messages_count == map->hdr.messages_count) .. deliver(xxxxxx@xxxxxx): file mail-index.c: line 983 (mail_index_sync_from_transactions): assertion failed: (hdr.messages_count == (*map)->hdr.messages_count)
I hoped these were completely fixed in v1.0. What filesystem do you use?
IBM's GPFS on linux, which is a shared disk cluster fs.
So either there's some problem that only occurs with GPFS or it adds enough latency that a race condition somewhere can cause problems. Before v1.0 release I was running imap stress testing for many hours (reading and modifying the same mailbox) without a single error, so I doubt I can reproduce this myself. And if I can't reproduce it, this is going to be pretty much impossible to fix.
For Dovecot v1.1 I'm going to simplify the index file code so at least then this error should hopefully go away.
Those are all assertion failures. Doesn't your MTA treat deliver crashes as temporary failures which are retried?
No, sorry.. postfix seems to be bouncing when deliver dies from signal 6.:
So it seems. If you're using syslog, you could use the attached patch. But maybe this should be changed in Postfix side? I guess I could try asking in Postfix list if they've something against it. You could anyway change that by modifying src/global/pipe_command.c around line 630:
if (WIFSIGNALED(wait_status)) {
dsb_unix(why, "5.3.0", log_len ?
Change 5.3.0 to 4.3.0