Mailboxes corrupting (dovecot.index file)

Hi,

this is happening to me too. It was one incident 6 months or so ago. Then a couple here and there, but now I have had atleast 10 within the last few weeks telling me it has something to to with load or activity. Seems only to happen to very active users.

I started looking through the logs and found this beauty of someone whom I just deleted the dovecot*.* files from their mail dir to get it working again:

Code:

Apr  3 22:21:17 tor dovecot: pop3-login: Login: user=<ellingsen@*****.com>, method=PLAIN, rip=*.*.*.205, lip=*.*.*.207, mpid=23929, TLS, session=<zJjDJCn2lwAClhLN>
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Error: broken sync positions in index file /home/brensel/mail/*****.com/ellingsen/dovecot.index
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Warning: fscking index file /home/brensel/mail/*****.com/ellingsen/dovecot.index
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Error: Fixed index file /home/brensel/mail/*****.com/ellingsen/dovecot.index: log_file_tail_offset 176 -> 144
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Panic: file mail-transaction-log.c: line 350 (mail_transaction_log_set_mailbox_sync_pos): assertion failed: (file_offset >= log->head->saved_tail_offset)
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0 [0x2b73fe993a7a] -> /usr/lib64/dovecot/libdovecot.so.0 [0x2b73fe993ae6] -> /usr/lib64/dovecot/libdovecot.so.0 [0x2b73fe993473] -> /usr/lib64/dovecot/libdovecot-storage.so.0 [0x2b73fe6ea81b] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_commit+0x89) [0x2b73fe6e2069] -> /usr/lib64/dovecot/libdovecot-storage.so.0 [0x2b73fe66e20d] -> /usr/lib64/dovecot/libdovecot-storage.so.0 [0x2b73fe66d717] -> /usr/lib64/dovecot/libdovecot-storage.so.0 [0x2b73fe66da58] -> /usr/lib64/dovecot/libdovecot-storage.so.0(maildir_storage_sync_init+0xbb) [0x2b73fe66dbfb] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x31) [0x2b73fe69a391] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_sync+0x27) [0x2b73fe69cae7] -> dovecot/pop3(client_create+0x332) [0x405722] -> dovecot/pop3 [0x40414b] -> dovecot/pop3 [0x404708] -> /usr/lib64/dovecot/libdovecot.so.0 [0x2b73fe9512f2] -> /usr/lib64/d
Apr  3 22:21:19 tor dovecot: pop3(ellingsen@*****.com): Fatal: master: service(pop3): child 23929 killed with signal 6 (core dumps disabled)

 

Yes, that works every time, but the issue keep recurring and while the customer waits for it to be resolved by us his email service is unusable.

I will open a support case.

 

Hi! I have same problem with my clients.
I already tried to clean dovecot files, but doesn't works.
If you found a solution, can you update this topic?

Thanks!

 

I solved my problem. In my case occurred when trying to delete any email.
I was deleting the dovecot files from wrong folder (excluding the root folder).
In my error log specified the directory that the problem was occurring:

Code:

Apr 14 12:49:13 vps dovecot: imap(account@domain.com): Warning: fscking index file /home/domain/mail/domain.com/account/.Trash/dovecot.index 

Only took into this directory and remove the dovecot files.

 

Support Request Id 4879553 is currently open and being investigated

 

That didn't help, as I still got errors later that day, about 30 minutes after changing the number of available authentication daemons, but oddly do not have any the last 2 days. I have a little hope that maybe the last errors really were the last ones and some log processing time or the likes accounts for that 30-45 min gap.

Cpanel now has core dumps from the server when the error occurred, so hopefully that will tell them something.

 

Has there been any update on your ticket? I am having this exact same issue. larger/more frequently used mailboxes are having the index files become corrupt. At least 1-2 times a month

 

Sorry, I forgot about this thread.

Unfortunately I am not able to update the Kernel, so I cannot test that. I would have to migrate the whole VPS to a new platform, and I'm just not willing to do that with as many users as are on the box in question.

I am seeing improvements from just tweaking the authentication daemons as stated above though. At least I assume it must be from that. The issue is much rarer again now.

 

As far as i have seen, deleting the corrupted index file is the only solution. It would be better to
run a cron to remove the file once in a while ( since its automatically regenerated )