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