mailboxes.db discrepancies between mailbox and mupdate servers

[Dave McMurtrie]

On 7/9/13 3:04 PM, "Shawn Winnington-Ball" <swball at uwaterloo.ca> wrote:

>Hi all,
>
>I'm having an issue with a Cyrus murder wherein the mupdate server
>believes that a set of mailboxes are in mid-transfer, when in fact
>they don't exist on any of the downstream mailbox servers.  Here's
>an example of a lone entry gleaned from the output of `ctl_mboxlist
>-d' run on the mupdate server:
>
>user.foo	3 mailbox-03-internal!spool
>
>If I login to mailbox-03 and use `cyradm' to create the mailbox
>directory for user.foo, I get
>
>createmailbox: unable to reserve mailbox on mupdate server
>
>It seems that I need to get these sorts of entries removed from the
>mupdate server's mailboxes.db file so that I can go about creating
>the mailboxes afresh.

If you log in to mailbox-03-internal and run:

# ctl_mboxlist -d | grep "^user\.foo"

is anything returned?  For that matter, run this on each of your backend
servers and see if it exists anywhere.

>
>My question is how to do this?  Looking through this list's archives,
>I see that the cyr_dbtool command can be used to query and manipulate
>the mailboxes.db file itself, but someone mentioned that it's best
>not to modify the mupdate server's mailboxes.db file directly.  In
>my case, if I were to try running
>
>cyr_dbtool /path/to/mailboxes.db skiplist delete 'user.foo'
>
>on the mupdate server, would I be taking an unnecessary risk?

It might be safer to clear the reserved state via mupdate protocol.  You
can do this manually by using mupdatetest.  You can google for the mupdate
RFC if you want more details about the protocol, but basically:

$ mupdatetest your.mupdate.server.com.
1 ACTIVATE "user.foo" "mailbox-03-internal!spool" "foo" "lrswipcda"



>  Are
>there other means by which to force mailbox-03 to report a complete
>and accurate list of its mailboxes to the mupdate server, thereby
>overwriting those mailboxes.db entries marked `in-transit' ?


You can force a backend to push all of its mailboxes to the mupdate master
by running "ctl_mboxlist -m" on the backend.  If you're not 100% sure
whether you want to push every mailbox before you know what state things
are in, you can individually push mailboxes, again using mupdate protocol.
 Log in to the backend and run

$ mupdatetest your.mupdate.server.com.
1 MUPDATEPUSH user.foo

I don't think a mupdate push will change the RESERVED state of the
mailbox, though.

HTH,

Dave