Hi, I have a couple of people bumping into an issue with their imap process crashing - from the users perspective, their mail client (thunderbird) just stops recieving new mail. It still seems to be possible for them to read their mail using squirell mail. When it crashes, it leaves behind a log message like this on the server:
Aug 12 15:52:25 fury dovecot: imap-login: Login: user=<zhi>, method=PLAIN, rip=10.8.5.15, lip=10.10.0.26 Aug 12 15:52:25 fury dovecot: IMAP(zhi): Panic: file istream.c: line 99 (i_stream_read): assertion failed: ((size_t)ret+old_size == _stream->pos
- _stream->skip) Aug 12 15:52:25 fury dovecot: IMAP(zhi): Raw backtrace: imap [0x49ddc0] -> imap [0x49de23] -> imap [0x49d4a6] -> imap [0x4a252e] -> imap [0x4a4691] -> imap(i_stream_read+0x48) [0x4a23f8] -> imap(i_stream_read_data+0x28) [0x4a2558] -> imap [0x4ab22e] -> imap(o_stream_send_istream+0x2e) [0x4aa63e] -> imap(maildir_save_continue+0x32) [0x443d12] -> imap(mail_storage_copy+0x6a) [0x462a1a] -> imap(maildir_copy+0x5e) [0x441d2e] -> imap(cmd_copy+0x1fe) [0x41a94e] -> imap(cmd_uid+0x78) [0x41f8d8] -> imap [0x42053c] -> imap [0x4205f2] -> imap(client_handle_input+0x3f) [0x42072f] -> imap(client_input+0x5f) [0x42127f] -> imap(io_loop_handler_run+0xf8) [0x4a5b08] -> imap(io_loop_run+0x1d) [0x4a4c1d] -> imap(main+0x620) [0x428b80] -> /lib64/libc.so.6(__libc_start_main+0xf4) [0x353e41d974] -> imap [0x4198f9] Aug 12 15:52:25 fury dovecot: dovecot: child 14759 (imap) killed with signal 6 (core dumps disabled)
I was able to fairly reliably trigger the same behaviour myself by attempting to move a bunch (thousands) of emails in my account using thunderbird - I dont know exactly what it is that triggers the crash though. I tried enabling core dumps using 'ulimit -c unlimited' and messing around with some environment variables to stop the startup scripts from forcing core dumps off again (DAEMON_COREFILE_LIMIT=18446744073709551615 /etc/init.d/dovecot restart). After doing that, I do not see anything in the logs any more - but I still seem to be having problems moving the emails around in my account. It would seem that it is still broken but Im just not getting any logs telling me so. There don't seem to be any core dumps sitting around anywhere either.
My 'dovecot -n' is: # 1.2.3: /etc/dovecot.conf # OS: Linux 2.6.18-128.1.16.el5.centos.plus x86_64 CentOS release 5.3 (Final) xfs syslog_facility: local0 shutdown_clients: no login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login max_mail_processes: 1024 first_valid_uid: 300 mail_location: maildir:/u/%u/Maildir mail_drop_priv_before_exec: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib64/dovecot/imap mail_plugin_dir(imap): /usr/lib64/dovecot/imap mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3 lda: postmaster_address: example@example.com auth default: mechanisms: gssapi gss-spnego plain krb5_keytab: /etc/opt/quest/vas/imap.keytab gssapi_hostname: $ALL passdb: driver: passwd-file args: /etc/dovecot.deny # empty file deny: yes passdb: driver: pam args: dovecot userdb: driver: passwd userdb: driver: static args: home=/u/%u
-- Thanks, Phill Macey