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
