Stuck mailboxes.db entries with mbtype=2

Michael Bacon baconm at email.unc.edu
Tue Aug 24 13:39:07 EDT 2010



--On August 24, 2010 1:22:53 PM -0400 Dave McMurtrie 
<dave64 at andrew.cmu.edu> wrote:

> On 08/24/2010 01:17 PM, Michael Bacon wrote:
>
>>
>> Definitely something I hadn't thought of, but in this case, the faulty
>> mbtype appears to be in the mailboxes.db on the backend server, not the
>> mupdate server. I don't think an MUPDATE command would change that,
>> would it?
>
> If your mupdate master still doesn't have a mailbox entry for the broken
> user(s), but the backend server has it locally in mailboxes.db, you can
> force a mupdate push from the backend first, then clear the reserved
> state.
>
> To force the backend to do a mupdate push, use imtest:
>
> $ imtest -m GSSAPI your.cyrus.backend.com.
> S: A01 OK Success (privacy protection)
> Authenticated.
> 1 MUPDATEPUSH user.testuser
> 1 OK Completed
> 2 logout
> * BYE LOGOUT received
> 2 OK Completed
> Connection closed.


The mupdate server is fine -- it has the mailbox on the right server, on 
the right partition, with the right mbtype (1, i.e. remote mailbox).  The 
backend server is the one with the messed-up mailboxes database.  It has 
the mailbox, but it has it with mbtype=2, which is "reserved."  Any attempt 
to delete, change, or select the mailbox results in the error message, 
"Mailbox is currently reserved."

My understanding of the matter is that when any backend cyrus process goes 
to do something on a mailbox such as add, delete, rename, or xfer, it puts 
the mailbox into reserved state (mbtype=2) in the local mailboxes database. 
When it finishes, it either sets the mailbox back to normal, or it removes 
the entry.  The problem is, we had a state where some but not all writes to 
the *local* mailboxes database failed (not the mupdate server).  As such, 
some mailboxes got put into the reserved state but never removed from it, 
and now I can't either take them out of that state or delete them (deleting 
them would be fine at this point).

We got into this state by having three backend servers with bad file system 
permissions, so it's not as if cyrus got this way through normal 
operations.  I just can't seem to undo it.  From what I can tell, 
reconstruct and the various ctl_mboxlist commands will fix many errors, but 
they won't change the mbtype.

-Michael 


More information about the Info-cyrus mailing list