Unexpected database recovery

[Richard Gilbert]

Yesterday I applied John Wade's lock_flock patch to the version of Cyrus
impad we were already running, i.e. 2.1.14 and rebuilt and reinstalled.
cyrus-imapd was restarted at 5 am this morning to minimise inconvenience
to users.  I was surprised to find that the system was unavailable until
about 08:39 because of database recovery.

Nov 19 05:00:11 impala master[9697]: [...] process started
Nov 19 05:00:11 impala ctl_cyrusdb[9698]: [...] recovering cyrus databases
Nov 19 05:05:10 impala ctl_mboxlist[10854]: [...] skiplist: recovered
	/var/imap/mailboxes.db (61786 records, 4909724 bytes) in 9 seconds
Nov 19 08:38:54 impala ctl_cyrusdb[9698]: [...] done recovering cyrus databases
Nov 19 08:38:54 impala master[9697]: [...] ready for work
Nov 19 08:38:54 impala ctl_cyrusdb[22419]: [...] checkpointing cyrus databases

My question is: was this database recovery caused by the system realising
that the software had changed, or was it a complete coincidence?  We
restart the system three times a week at 5am and this has not happenned
before, as far as I know.

It's a bit early to say, but the number of lockers in the "DBERROR db3: N
lockers" is staying very low today -- rarely anything other than 2.  I'm
touching wood and crossing my fingers even as I type!

Richard
--
Richard Gilbert
Corporate Information and Computing Services
University of Sheffield, Sheffield, S10 2TN, UK
Phone: +44 114 222 3028   Fax: +44 114 222 3040