--- Telnet session --- $ telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. * OK Dovecot ready. a login user1 password a OK Logged in. b select inbox * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 1 EXISTS * 1 RECENT * OK [UNSEEN 1] First unseen. * OK [UIDVALIDITY 1218731580] UIDs valid * OK [UIDNEXT 2] Predicted next UID b OK [READ-WRITE] Select completed. c fetch 1 rfc822.size Connection closed by foreign host.
--- Error log ---dovecot: Aug 29 11:24:30 Info: imap-login: Login: user=<user1>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured dovecot: Aug 29 11:24:33 Error: IMAP(user1): Corrupted transaction log file /Volumes/Spool/spool/user1/mail/dovecot.index.log: hdr.size too large (75497472) dovecot: Aug 29 11:24:33 Warning: IMAP(user1): fscking index file / Volumes/Spool/spool/user1/mail/dovecot.index
dovecot: Aug 29 11:24:48 Error: child 66917 (imap) killed with signal 11 --- Backtrace --- mail_cache_header_fields_get_offset + 214 mail_cache_header_fields_read + 37 mail_cache_open_and_verify + 167 mail_cache_field_exists + 77 index_mail_set_seq + 306 index_storage_search_next_nonblock + 464 mailbox_search_next + 52 imap_fetch + 345 cmd_fetch + 639 client_command_input + 33 client_command_input + 463 client_handle_input + 242 client_input + 151 io_loop_handler_run + 272 io_loop_run + 39 main + 1671 start + 52If I do the exact same telnet all over again, the imap process crashes in the same place, but without reporting the "fscking index file" error first. Attached are all the post-fsck dovecot* files from the user's inbox maildir.
For other users I see this error before imap crashes:dovecot: Aug 29 11:45:23 Error: IMAP(user2): Rebuilding index file / Volumes/Spool/spool/user2/mail/dovecot.index: CPU architecture changed Attached are pre- and post-rebuild copies of that user's dovecot* files, and also a copy from after a second telnet session which also crashed.
It's possible this is a 32/64-bit incompatibility issue (imap is a 64- bit program for me; mail might have been delivered by a 32-bit deliver or previously read by a 32-bit imap) but more likely the dovecot* files are just hosed in some way.
I can provide more information if you ask soon, but I can't keep this server broken for too long.
user1-post.tgz
Description: Binary data
user2-pre.tgz
Description: Binary data
user2-post.tgz
Description: Binary data
user2-final.tgz
Description: Binary data
