--On Monday, February 13, 2006 2:19 PM -0500 Ken Murchison <[EMAIL PROTECTED]> wrote:
Nicolas KOWALSKI wrote:Hello, I am testing the migration from a 2.2.12 installation, compiled with the default options (./configure without any option), to a 2.3.1 installation, also compiled with the default options. The databases used are the default for both. The system is Debian 3.1, using db3 for the berkeley databases (but this should not matter because we do not use tls caching or duplicate suppression). When I start the server using the new binaries, accessing some mailboxes is not possible, the server sending a "mailbox has invalid format" error. If I run reconstruct on these mailboxes, everything runs fine afterwards. Did I forget something ? Should I run reconstruct unconditionnaly on all mailboxes to prevent any inconsistencies during upgrades ?You shouldn't have to do a reconstruct unless there truely is something wrong with the mailbox. The various services are supposed to do an on-the-fly upgrade of the mailboxes.
What system are you running this on?
Last year, we upgraded from 2.2.1 to 2.2.10. Our system is a Tru64 Alpha
Cluster and we ran into exactly the same problem with the same response...
Cyrus should automatically upgrade the mailboxes when the user logs in or
LMTP does a delivery of a message.
What I found was that in all my testing, this was exactly the case. I
even did stress testing and could not get Cyrus to *not* upgrade the
mailboxes. However, when we moved to production, our production system
seemed to upgraded some user's mailboxes, but produced the above error
other user's mailboxes. As more and more users logged on, the errors
increased in frequency and the problem got worse. The users that got
the errors had to have their mailboxes reconstructed before they could
log in and check their mail.
I have no idea why this happened, but it caused a lot of pain for us. We
backed out of the upgrade the first time and I spent quite a bit of time
trying to reproduce the problem without success. We tried the upgrade
again and the problem came back. This time, we decided to plow on. I
wrote a script that watched the syslogs for any user getting the above
error and immediately launched a reconstruct of their account. We ran
another parallel script that worked its way through all the accounts,
reconstructing everything (which took a long time to complete). Once all
the accounts were reconstructed, we have run fine ever since.
Anyways, I don't think that helps you much, but I thought I would share
my experience. I don't relish having to do this again on the next upgrade.
Scott
--
+-----------------------------------------------------------------------+
Scott W. Adkins http://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:[EMAIL PROTECTED]
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+-----------------------------------------------------------------------+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
pgpHLxSgvCuSN.pgp
Description: PGP signature
---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
