[Dovecot] Dovecot 1.x on AIX -> Dovecot 2.x on Ubuntu
We are working on migrating Dovecot 1.2.17 running on AIX 5.3 (believe it or not!) to Dovecot 2.0.13 running on Ubuntu. We have hundreds of users mboxes we will be migrating. My question is regarding the index files. Should we remove those after the migration, but before we open it up to users so Dovecot can create new ones?
I did a test migration of a single user, and Dovecot detects the architecture change and put out some panic errors, corrupt files and backtrace messages in syslog on Ubuntu. The messages are shown below. If every user is going to generate these types of errors, I'm thinking maybe it makes sense to remove all the .imap directories and let Dovecot create new clean ones. I realize that may slow things down for awhile while Dovecot is rebuilding new files.
Thanks for any info.
Jackie Hunt Acad Computing & Networking Srvcs Colorado State University
Jun 6 13:43:02 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19593, TLS Jun 6 13:43:21 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19597, TLS Jun 6 13:43:21 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19600, TLS Jun 6 13:44:11 newlamar dovecot: imap(cacti): Disconnected: Logged out bytes=107/441 Jun 6 13:44:11 newlamar dovecot: imap(cacti): Disconnected: Logged out bytes=1676/2724868 Jun 6 13:44:11 newlamar dovecot: imap(cacti): Disconnected: Logged out bytes=129/759 Jun 6 13:51:49 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19657, TLS Jun 6 13:51:49 newlamar dovecot: imap(cacti): Error: Rebuilding index file /adhome/cacti/.imap/INBOX/dovecot.index: CPU architecture changed Jun 6 13:51:58 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19662, TLS Jun 6 13:51:58 newlamar dovecot: imap(cacti): Error: Corrupted transaction log file /adhome/cacti/.imap/Trash/dovecot.index.log seq 16777216: log file shrank (1428 < 6144) (sync_offset=6144) Jun 6 13:51:58 newlamar dovecot: imap(cacti): Panic: file buffer.c: line 295 (buffer_set_used_size): assertion failed: (used_size <= buf->alloc) Jun 6 13:51:58 newlamar dovecot: imap(cacti): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x374fa) [0x7f3ada59c4fa] -> /usr/lib/dovecot/libdovecot.so.0(+0x3753e) [0x7f3ada59c53e] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f3ada576837] -> /usr/lib/dovecot/libdovecot.so.0(+0x35319) [0x7f3ada59a319] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_transaction_log_file_open+0x21e) [0x7f3ada87acee] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_transaction_log_open+0xb8) [0x7f3ada877a68] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_open+0xe5) [0x7f3ada860e75] -> /usr/lib/dovecot/libdovecot-storage.so.0(index_storage_mailbox_open+0xbc) [0x7f3ada826eac] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0x5f7fb) [0x7f3ada8417fb] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0x28c4c) [0x7f3ada80ac4c] -> /usr/lib/dovecot/libdovecot-storage.so.0(index_storage_mailbox_enable+0x24) [0x7f3ada827584] -> dovecot/imap(imap_status_get+0xfd) [0x7f3adacead8d] -> doveco t/imap(cmd_status+0x182) [0x7f3adace1f92] -> dovecot/imap(+0x1105d) [0x7f3adace405d] -> dovecot/imap(+0x11135) [0x7f3adace4135] -> dovecot/imap(client_handle_input+0x125) [0x7f3adace4385] -> dovecot/imap(client_input+0x65) [0x7f3adace4c35] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x48) [0x7f3ada5a8048] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xa7) [0x7f3ada5a90c7] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x28) [0x7f3ada5a7fd8] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f3ada5962c3] -> dovecot/imap(main+0x2f4) [0x7f3adacdc544] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f3ada1e530d] -> dovecot/imap(+0x95d5) [0x7f3adacdc5d5] Jun 6 13:51:59 newlamar dovecot: imap-login: Login: user=<cacti>, method=PLAIN, rip=129.82.100.64, lip=129.82.100.124, mpid=19664, TLS Jun 6 13:51:59 newlamar dovecot: imap(cacti): Error: Transaction log file /adhome/cacti/.imap/Trash/dovecot.index.log: marked corrupted Jun 6 13:51:59 newlamar dovecot: imap(cacti): Error: Rebuilding index file /adhome/cacti/.imap/Trash/dovecot.index: CPU architecture changed
root@yuma.acns.colostate.edu wrote:
We are working on migrating Dovecot 1.2.17 running on AIX 5.3 (believe it or not!) to Dovecot 2.0.13 running on Ubuntu. We have hundreds of users mboxes we will be migrating. My question is regarding the index files. Should we remove those after the migration, but before we open it up to users so Dovecot can create new ones?
I did a test migration of a single user, and Dovecot detects the architecture change and put out some panic errors, corrupt files and backtrace messages in syslog on Ubuntu. The messages are shown below. If every user is going to generate these types of errors, I'm thinking maybe it makes sense to remove all the .imap directories and let Dovecot create new clean ones. I realize that may slow things down for awhile while Dovecot is rebuilding new files.
Which mail storage format (mbox,maildir,sdbox,mdbox) are you using and is it stored on NFS?
Would you provide your "doveconf -n" output for dovecot 2.0.13, please?
You might also have a look at imapsync[1] for clean mass migration from one architecture to another.
Regards Daniel
On 6.6.2012, at 23.27, root@yuma.acns.colostate.edu wrote:
We are working on migrating Dovecot 1.2.17 running on AIX 5.3 (believe it or not!) to Dovecot 2.0.13 running on Ubuntu. We have hundreds of users mboxes we will be migrating. My question is regarding the index files. Should we remove those after the migration, but before we open it up to users so Dovecot can create new ones?
I did a test migration of a single user, and Dovecot detects the architecture change and put out some panic errors, corrupt files and
Yeah, there's still some problem with properly handling index file recreation when CPU architecture (endianess) change is detected. Better just delete your index files, since they have to be regenerated anyway.
participants (3)
-
Daniel Parthey
-
root@yuma.acns.colostate.edu
-
Timo Sirainen