DBERROR: skiplist recovery mailboxes.db 0090 - suddenly all is failing!

[Andrew Morgan]

On Mon, 5 Mar 2007, Gregor Wenkelewsky wrote:

> I don't really know about that. Here is from the log during another
> "controlled shutdown and reboot", of course I had to make sure that my
> mailboxes.db error would not occur on every reboot. (It did not occur
> again.) These are the last lines, no sign of a kill -9 signal:
>
> Feb 28 15:20:05 Server cyrus/master[3869]: exiting on SIGTERM/SIGINT
> Feb 28 15:20:13 Server postfix/master[4103]: terminating on signal 15
> Feb 28 15:20:15 Server exiting on signal 15

That is what I get when I shutdown Cyrus.

> When the error happened, a squatter run was completed about half an
> hour before, and ctl_cyrusdb "checkpointing cyrus databases" exactly
> 4 mins 27 secs before. And then, the last lines were:
>
> Feb 15 08:10:27 Server cyrus/master[3795]: exiting on SIGTERM/SIGINT
> Feb 15 08:10:35 Server postfix/master[4104]: terminating on signal 15
>
> "Server exiting" is missing!?!??!

I guess Cyrus couldn't exit cleanly?  I haven't seen that here.

> How do you recognize a corruption? I think it would be useful to have
> and automated e-mail been sent as soon as some error occurs, so that
> I can get to the system and fix it.

Our users will tell us that they cannot open their mailbox when their seen 
file is corrupted.  If I remember correctly, we see those skiplist errors 
in the logs too.

> Last time Cyrus just started to repeat trying and failing to open the
> db endlessly, thereby writing tons of messages to the log files until
> stopped. Hence the malfunction would not be obvious if no one wants to
> use e-mail during a few days (that is likely here) and no one checks
> the server (likely too).
> And hence that, I guess I should set up not just hourly, but daily and
> weekly dumps of mailboxes.db, because the last unsoiled hourly backup
> would be overwritten with an faulty backup after just one hour.
> Am I right?

I don't think the dump would be successful if mailboxes.db was corrupted, 
but honestly I don't know.  You are probably correct that adding some 
robustness to the dump process is a good idea.

 	Andy