zmmailboxmove and "Your session has expired..."

[AnthonyBurton]

I decided today to use the zmmailboxmove CLI utility to migrate users mailboxes from one of our mailbox servers to another. This is the first time I have used the utility, and I just wanted to post the results, and also maybe get feedback on how to check the progress (that'll make more sense in a second).

In the admin guide it recommends verifying the account after the mailbox is moved as you do in the Web UI version of this task. So after the zmmailboxmove command finished (or appeared to finish) I went to the admin interface and tried to "View Mail". When I did this I got the error message, "Your session has expired. Please log in again." But, of course, when I tried to log in, I could not.

I've spent a lot of time with Zimbra at this point, and I've come to expect this kind of behavior, and having that general sense of "WtF is it doing now?" when dealing with Zimbra. Things always seem to come out OK, but I hate that middle ground (and I seem to spend a lot of time there, unfortunately).

Eventually after 20 minutes or so, I went back to the admin Web UI and was able to View Mail on the account. There was just not anything obvious I could see that there was something still happening in the background. I had top running on the two servers in question, and running ps and zmprov commands.

So, do any of you have any suggestions as to what I could look at to see the progress of a move such as this?

I kept running different variants of zmprov commands, and it appeared that the account had transferred just fine, but I also kept reading posts about moving from 32bit to 64bit platforms, but I didn't think that fit my case since I've been running 32bit servers along side 64bit servers for over a year now, without any problems.

-tia-

[heri]

It was my first time using too, and the CLI just hung there. Guess i should have tried it on a small test account first.

Heri

[dustys]

I have just started working with the zmmailboxmove utility. To monitor what its doing, I use a combination of tail and grep on the mailbox.log.

tail -f /opt/zimbra/log/mailbox.log | grep test@test.com

This will give you events for the account and I see events from the backup and mailbox process that are in relation to the move. A progress indicator, would be nice, but this lets me know it's working.

Cheers,
Dusty

[LMStone]

I may not be reading the OP's post correctly, but it is not clear to me what expired: the session on the Admin Console or the ssh session in which the zmmailboxmove CLI was being run.

What we do on the Linux boxes from which we ssh into our Zimbra boxes is add the following line to /etc/ssh/ssh_config (NOT sshd_config!):

ServerAliveInterval 60

BTW, ssh_config is the file that controls how the ssh client (local workstation) behaves. The addition of this line has the ssh client sending periodic keep-alives to the ssh server (the Zimbra server), eliminating the need for appending "NOHUP" to commands and allowing you to let long-running commands complete without timing out.

Hope that helps,
Mark

[AnthonyBurton]

Your confusion mirrors mine!

What happened is that when you run the command on the command line, the command returns (meaning you get a command prompt back/you're able to run another command) which implies to me that the command is finished.

But it's not! And the only way to know is to do something like what dustys recommends.

The session expired error is utterly incorrect and therefore adds confusion. There is no expired session, it's just that the transfer operation has not yet finished.

[LMStone]

What happened is that when you run the command on the command line, the command returns (meaning you get a command prompt back/you're able to run another command) which implies to me that the command is finished.

But it's not!

That's WAD for Zimbra in IBM-speak (Working As Designed).

The command prompt returning doesn't mean the command has finished processing behind the scenes. It only means that Zimbra doesn't need any more info from you to do what you have asked it to do, and so it gives you back the command prompt so you can enter another command. From that standpoint, we find Zimbra's cli commands to be very admin-friendly, because they don't waste your time hanging a commandline session just to wait for some background I/O to complete.

What zmmailboxmove doesn't do that, say, zmbackup -f -a all does do is spit back something at you to let you know that things are in motion OK.

When you initiate a full backup of all accounts from the commandline, you'll get the prompt back in a few seconds, with the name of the backup. But if you have a big mail store and haven't done any backups in a while, you know that you will need to wait minutes if not hours for the backup to complete.

Same for zmmailboxmove; if you are moving for example a 2GB mailbox, even on a gig switch, moving that much data takes longer than the time it takes to get a command prompt back.

But now that we are on 5.0.15, we can move mailboxes via the Admin Console (bug fix after our previous version of 5.0.8).

Hope that helps!
Mark

[bill.carlson]

I've been doing some mailbox moves myself, here's my notes and observations.

zmmailboxmove doesn't return right away like zmbackup, but when it does return, that doesn't mean the mailbox is ready to use. Check via:

zmprov ga <account> | grep AccountStatus

When it's at active, it's ready to use.

One should use screen or a similar utility to make sure a dead shell session doesn't screw up the move (bash users, backupground and disown -h <jobid> if you already started without screen).

[fowler]

I have just started working with the zmmailboxmove utility. To monitor what its doing, I use a combination of tail and grep on the mailbox.log.

tail -f /opt/zimbra/log/mailbox.log | grep test@test.com

This will give you events for the account and I see events from the backup and mailbox process that are in relation to the move. A progress indicator, would be nice, but this lets me know it's working.

The above is more complete, as it shows lmtp bouncing messages and user access while the migration is taking place. To limit it just to the progress of the migration, I use:

tail -f mailbox.log  | awk '/ExportMailboxRequest.*?test\@/test.com'