[Dovecot] FETCH for mailbox got too little data
Using 1.1.1. Got this error message in a tight loop, using both Tbird and Mulberry 3 as client:
FETCH for mailbox INBOX UID 32994 got too little data: 1616 vs 1649
I get this repeatedly alternating with a login line. What does this mean?
I stopped the server, zipped ~/mail/.imap/INBOX to hide it and let dovecot recreate it, and things seem to be working again. Is there a less destructive way to fix this in the future?
Delivery is by procmail.
On Tue, 2008-07-01 at 12:39 -0700, Kenneth Porter wrote:
Using 1.1.1. Got this error message in a tight loop, using both Tbird and Mulberry 3 as client:
FETCH for mailbox INBOX UID 32994 got too little data: 1616 vs 1649
I get this repeatedly alternating with a login line. What does this mean?
I stopped the server, zipped ~/mail/.imap/INBOX to hide it and let dovecot recreate it, and things seem to be working again. Is there a less destructive way to fix this in the future?
Delete dovecot.index.cache file. Although I thought v1.1 did this automatically.
--On Tuesday, July 01, 2008 10:51 PM +0300 Timo Sirainen <tss@iki.fi> wrote:
Delete dovecot.index.cache file. Although I thought v1.1 did this automatically.
Is this file obsolete? Should I remove it for all folders, or just ones that exhibit a problem? (I see many of them in the folder hierarchy.)
On Tue, 2008-07-01 at 13:25 -0700, Kenneth Porter wrote:
--On Tuesday, July 01, 2008 10:51 PM +0300 Timo Sirainen <tss@iki.fi> wrote:
Delete dovecot.index.cache file. Although I thought v1.1 did this automatically.
Is this file obsolete? Should I remove it for all folders, or just ones that exhibit a problem? (I see many of them in the folder hierarchy.)
It contains cached data which speeds up Dovecot's replies to clients. So delete them only if you see problems for a specific mailbox. They're recreated the next time user opens the mailbox.
--On Tuesday, July 01, 2008 11:36 PM +0300 Timo Sirainen <tss@iki.fi> wrote:
It contains cached data which speeds up Dovecot's replies to clients. So delete them only if you see problems for a specific mailbox. They're recreated the next time user opens the mailbox.
After the error message is logged, the code in imap_fetch_send() invokes this:
mail_set_cache_corrupted(ctx->mail, ctx->cur_size_field);
What uses that? Is that supposed to ultimately prevent the retry from using the cache file? It seems like that mechanism isn't working, as the client was getting into a loop.
I've now enabled error logging to a separate log file and see this on today's occurrence:
dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Next message unexpectedly lost from 41838245 dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Next message unexpectedly lost from 41838245 dovecot: Jul 08 09:42:39 Panic: IMAP(mortal): file message-parser.c: line 770 (message_parser_parse_next_block): assertion failed: (ctx->input->eof || ctx->input->closed || ctx->input->stream_errno != 0 || ctx->broken) dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Raw backtrace: imap [0x80cfc80] -> imap [0x80cfcda] -> imap [0x80cf57c] -> imap(message_parser_parse_body+0) [0x80c8e00] -> imap(index_mail_cache_parse_continue+0x22) [0x8094102] -> imap [0x807cd81] -> imap(mbox_save_continue+0x38) [0x807ce28] -> imap(mail_storage_copy+0xe4) [0x809e5e4] -> imap(cmd_copy+0x1d2) [0x805b252] -> imap(cmd_uid+0x59) [0x805f4e9] -> imap [0x805fe8c] -> imap [0x805ff35] -> imap [0x80606f5] -> imap(client_input+0x5e) [0x806090e] -> imap(io_loop_handler_run+0x100) [0x80d75d0] -> imap(io_loop_run+0x28) [0x80d6748] -> imap(main+0x4ac) [0x806845c] -> /lib/libc.so.6(__libc_start_main+0xdc) [0xc2edec] -> imap [0x805a271] dovecot: Jul 08 09:42:39 Error: child 31406 (imap) killed with signal 6
participants (2)
-
Kenneth Porter
-
Timo Sirainen