Following errors have happened quite a bit: Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): Transaction log file /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: marked corrupted Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): Transaction log file /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log.2: marked corrupted Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): Corrupted transaction log file /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: Append with UID 50, but next_uid = 15870 Causing Peter Day not to be able to delete emails. Seems mostly to happen in the Trash I think. Shouldn't Dovecot be able to recover from this? And then have some rule that if it cannot recover, delete the index file and rebuild? When I manually remove the file it works fine. Thanks, Daniel
On Fri, 2007-12-07 at 14:33 +0000, Daniel Watts wrote:> Following errors have happened quite a bit: > > Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): > Transaction log file > /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: > marked corrupted > > Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): > Transaction log file > /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log.2: > marked corruptedThese happen because of another error that caused them to be marked corrupted.> Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): > Corrupted transaction log file > /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: > Append with UID 50, but next_uid = 15870This is the real error. What kind of a system do you have? Do you use NFS or other shared filesystem? Post your dovecot -n output?> Shouldn't Dovecot be able to recover from this?It does, that's why there are those "marked corrupted" errors. But it probably does cause the current operation to fail. v1.1 handles this by logging the error but continuing anyway, so the operation shouldn't fail. If you mean that it repeatedly fails with the same error, then the same error condition is created over and over again for some reason. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20071207/1e5b7bdd/attachment-0002.bin>
151.189.12.245 i18n.kde.org [snip]> >> Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): >> Corrupted transaction log file >> /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: >> Append with UID 50, but next_uid = 15870 >> > > This is the real error. What kind of a system do you have? Do you use > NFS or other shared filesystem? Post your dovecot -n output? > >Standard local disk partition. No NFS. tg3 daniel # dovecot -n # 1.0.7: /etc/dovecot/dovecot.conf syslog_facility: local5 protocols: imap imaps pop3 pop3s listen(default): *:143 listen(imap): *:143 listen(pop3): *:110 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(pop3): *:995 ssl_cert_file: /var/ssl/certs/imapd.pem ssl_key_file: /var/ssl/private/imapd.pem disable_plaintext_auth: 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 login_process_per_connection: no login_processes_count: 5 verbose_proctitle: yes default_mail_env: maildir:/home/virtual/%h mail_location: maildir:/home/virtual/%h mail_full_filesystem_access: yes mmap_disable: yes dotlock_use_excl: yes fsync_disable: yes maildir_copy_with_hardlinks: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_process_size: 128 mail_plugins(default): imap_quota quota mail_plugins(imap): imap_quota quota mail_plugins(pop3): quota mail_plugin_dir: /usr/lib/dovecot/imap mail_log_max_lines_per_sec: 30 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): outlook-idle pop3_uidl_format: %08Xv%08Xu namespace: type: private separator: / inbox: yes namespace: type: private separator: / prefix: mail/ location: maildir:/home/virtual/%h hidden: yes auth default: cache_size: 2048 cache_ttl: 900 master_user_separator: * worker_max_count: 5 passdb: driver: passwd-file args: /etc/master.pwd master: yes passdb: driver: sql args: /etc/dovecot-mysql.conf userdb: driver: sql args: /etc/dovecot-mysql.conf plugin: quota: maildir>> Shouldn't Dovecot be able to recover from this? >> > > It does, that's why there are those "marked corrupted" errors. But it > probably does cause the current operation to fail. v1.1 handles this by > logging the error but continuing anyway, so the operation shouldn't > fail. > > If you mean that it repeatedly fails with the same error, then the same > error condition is created over and over again for some reason. >Yes it repeatedly fails until I manually remove the index files. However after removing them it does not seem to reoccur. Thanks Timo, Dan
[snip]> >> Dec 7 14:19:26 locallog at tg3/tg3 dovecot: IMAP(peter.day at mydomain.com): >> Corrupted transaction log file >> /home/virtual/mydomain.com/home/peter.day/Maildir/.Trash/dovecot.index.log: >> Append with UID 50, but next_uid = 15870 >> > > This is the real error. What kind of a system do you have? Do you use > NFS or other shared filesystem? Post your dovecot -n output? > >Standard local disk partition. No NFS. tg3 daniel # dovecot -n # 1.0.7: /etc/dovecot/dovecot.conf syslog_facility: local5 protocols: imap imaps pop3 pop3s listen(default): *:143 listen(imap): *:143 listen(pop3): *:110 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(pop3): *:995 ssl_cert_file: /var/ssl/certs/imapd.pem ssl_key_file: /var/ssl/private/imapd.pem disable_plaintext_auth: 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 login_process_per_connection: no login_processes_count: 5 verbose_proctitle: yes default_mail_env: maildir:/home/virtual/%h mail_location: maildir:/home/virtual/%h mail_full_filesystem_access: yes mmap_disable: yes dotlock_use_excl: yes fsync_disable: yes maildir_copy_with_hardlinks: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_process_size: 128 mail_plugins(default): imap_quota quota mail_plugins(imap): imap_quota quota mail_plugins(pop3): quota mail_plugin_dir: /usr/lib/dovecot/imap mail_log_max_lines_per_sec: 30 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): outlook-idle pop3_uidl_format: %08Xv%08Xu namespace: type: private separator: / inbox: yes namespace: type: private separator: / prefix: mail/ location: maildir:/home/virtual/%h hidden: yes auth default: cache_size: 2048 cache_ttl: 900 master_user_separator: * worker_max_count: 5 passdb: driver: passwd-file args: /etc/master.pwd master: yes passdb: driver: sql args: /etc/dovecot-mysql.conf userdb: driver: sql args: /etc/dovecot-mysql.conf plugin: quota: maildir>> Shouldn't Dovecot be able to recover from this? >> > > It does, that's why there are those "marked corrupted" errors. But it > probably does cause the current operation to fail. v1.1 handles this by > logging the error but continuing anyway, so the operation shouldn't > fail. > > If you mean that it repeatedly fails with the same error, then the same > error condition is created over and over again for some reason. >Yes it repeatedly fails until I manually remove the index files. However after removing them it does not seem to reoccur. Thanks Timo, Dan