murder setup - mailboxes.db corruption - trouble recovering with ctl_mboxlist

[Andrew Morgan]

On Thu, 20 Nov 2008, Wolfe, Eric G wrote:

> We are using skiplist, I copied the mailboxes.db to frontends.  If the 
> frontends are updating, it is not apparent.  I could not verify that 
> either of them were synching from the master after the mupdate master 
> synch.  Which is why I copied them to the frontends to speed things up.

I've tried this in the past for the same reasons, but it doesn't work. 
The only way I've been able to get the correct mailboxes.db on frontends 
is to let them sync with the mupdate master.  And yes, this takes a while 
from scratch when you are using skiplist because writes are much slower 
with skiplist.

> Strange that it would just start causing problems now.  We probably are 
> seeing a cascading effect of failure, with the backlog though.  Do the 
> latest vanilla trees, have these patches included in them?  The packages 
> here: http://cyrusimap.web.cmu.edu/downloads.html#imap.  I am somewhat 
> reluctant to upgrade things in a fragile state.  If these patches are 
> included in latest releases, is 2.3.13 a fairly painless upgrade path 
> from 2.2.12, or do we need to go with 2.2.13?

I wouldn't upgrade until you can get a working system.

> Is there anything we can turn off in the cyrus.conf or imapd.conf, to 
> work around this "bottleneck"?  In other words, can we keep the MTA from 
> knocking on the door for long enough to get everything running smoothly 
> again?

Yes, comment out lmtp in your cyrus.conf on the frontends.  After you have 
successfully synced mailboxes.db, enable lmtp again and restart cyrus on 
the frontends.  You probably should put some limits on lmtp as well.  We 
use maxchild=50 here (3 frontends).

> Ok, because it sounds like a problem of connecting to the mupdate master 
> port on 3905, to the unitiated.

Hard to say, but take the steps above to simplify the problem.  :)

 	Andy