I'll second this. I had the same thing happen to me after I had Cyrus 2.1.2 running for about a month. The problem is that if one of the .db files (i.e. mailboxes.db) gets corrupted and you haven't set up a "hot backup" of your db files, the recovery process has to go through EVERY db transaction in the log files that has occurred since you first got the server running. Going through a month of log files took my 1-GHz Athlon w/ ATA100 drives somewhere around thirty hours. I slapped together a replacement IMAP server in a few hours with some spare parts I had laying around, but by then most of the company had gone home for the day. Nobody was very happy with me. :-) At least they had my replacement to use the following day.
It would be nice if a description of how to set up a hot backup in a cron job was described as part of the installation procedure. (Though I didn't read all the docs during my last install, sorry if it's there already) Here is a description of how to set up a hot backup: http://www.sleepycat.com/docs/ref/transapp/archival.html -Jules On Sat, 2002-04-27 at 05:09, John Wade wrote: > Hi Warren, > > Take a look at the syslog, I would bet that cyrus is trying to recover the > duplicate delivery database or more probably the mailboxes database. For most > folks on linux, this should be in something like /var/log/imapd.log (although > it depends how you have syslog configured.) > > The syslog entries from a normal startup should look for something like: > > Apr 23 01:59:51 romulan master[847]: about to exec /usr/cyrus/bin/ctl_mboxlist > Apr 23 01:59:51 romulan ctl_mboxlist[847]: running mboxlist recovery > Apr 23 01:59:52 romulan ctl_mboxlist[847]: done running mboxlist recovery > Apr 23 01:59:52 romulan master[875]: about to exec /usr/cyrus/bin/ctl_deliver > Apr 23 01:59:52 romulan master[837]: ready for work > Apr 23 01:59:52 romulan master[877]: about to exec /usr/cyrus/bin/ctl_deliver > Apr 23 01:59:52 romulan master[876]: about to exec /usr/cyrus/bin/ctl_mboxlist > Apr 23 01:59:52 romulan ctl_mboxlist[876]: checkpointing mboxlist > Apr 23 01:59:52 romulan ctl_deliver[877]: duplicate_prune: pruning back 3 days > Apr 23 01:59:52 romulan master[837]: process 876 exited, status 0 > Apr 23 01:59:52 romulan ctl_deliver[877]: duplicate_prune: /var/imap/deliverdb/d > > eliver-a.db: purged 53 out of 143 entries > <snip -- 24 more entries cut out here> > Apr 23 01:59:54 romulan ctl_deliver[877]: duplicate_prune: /var/imap/deliverdb/d > > eliver-z.db: purged 5 out of 13 entries > Apr 23 01:59:54 romulan master[837]: process 877 exited, status 0 > > I would bet that the last entry in your syslog is: > <date> <server> ctl_mboxlist[<pid>]: running mboxlist recovery > > If this is what you see, the Berkeley DB mailboxes database has probably gotten > messed up and the recovery process is hanging If this is your problem, one fix > you could try would be to make backup copies of the /var/imap/mailboxes.db file > and /var/imap/db directory, then delete all the files in the db directory. > We use Berkeley DB's on our web server and this is the procedure we have used > when they die. > > Not sure if this leaves you with a completely consistent database, but you could > always export it out to a text file after you get it running using > > /usr/cyrus/bin/ctl_mboxlist -d > /var/imap/mailboxdb.txt > > Then delete the mailboxes.db and the contents of the /var/imap/db directory. > As a final step, reimport the mailboxes.db using > > /usr/cyrus/bin/ctl_mboxlist -u < /var/imap/mailboxdb.txt > > For paranoia's sake, we have a cron job that exports the mailboxes.db using > /usr/cyrus/bin/ctl_mboxlist -d every night. > > I am not a Berkeley db expert, so someone else may have more useful info. > > Good luck, > > John > > > > Warren Flemmer wrote: > > > Greetings > > > > After a bad restart of the cyrus server, imap, pop, cyradm and imtest fail > > to function. The server had been functioning without problem for about > > 6 months. A spare server was loaded with the backups, which had no > > problem starting imap and the rest. So the configuration before the restart > > was good. There were no changes made between the backup and the > > restart (it was only a day or two old). All other services on the server do > > not show any signs of problems (smtp,snmp, named etc work fine), only > > cyrus is showing problems. After the restart fsck had to be used. > > > > If I telnet onto 127.0.0.1 143 or 110 the connection is established but the > > banner does not appear. Cyradm never asks for the password unless I kill > > the master process, then I get password and broken pipe. imtest shows > > 'C: C01 CAPABILITY' but nothing else. > > > > Imap.conf and cyrus.conf are both good, the same as that on the server > > with the restored backup (that works). The permissions and files seem to be > > good and intact. I have reinstalled (make install) to ensure that cyrus > > files > > were not damaged. Reconstruct never returns (I have waited a number of > > hours, approx. 300 mailboxes, probably less than 10 megs per mail box). > > Setting the environment variable to CYRUS_VERBOSE shows no sign of > > a problem. > > > > The backup server is working fine, so the reason for getting the old server > > running is to get whatever mail is sitting on it to the new server and, > > if it > > happens again, the heavy handed approach of restoring from backups can > > be avoided. I have searched the archives, without finding a single problem > > matching this (similar, no banner problems, in the archives imply a > > config or > > permission problem and usually occur with new installations, this is not > > the > > case here). > > > > Config: RedHat 7.1, cyrus-imapd-2.0.16, pam is used for auth out of an mysql > > db. The db is intact and functioning. > > > > Any ideas welcome, I have run out of them. > > > > Regards >
