I moved a user's INBOX from one partition to another. Everything went well, except that the Sent folder was unintentionally left on the source partition. I performed this command to move the folder to the destination partition:
mboxutil -r user/<username>/Sent user/<username>/Sent new-partition
It got hung up every time during the process.
What can do I to move the folder back to its new partition?
If it's hanging, then likely something has the sent folder locked.
There are few ways to unlock. If there's already a mboxutil running, use ctrl <c> to stop it. Don't kill it, as that may leave it with a lock.
If youi've already killed one such, you must restart messaging Server with a stop-msg. Check that all messaging processes are stopped, and restart.
then try your move again.
I can kill the mboxutil jobs successfully, but for some odd reason it still doesn't work when I try to run the command. It's hanging up every time. what are the other ways for moving the folder from the source to its destination partition?
Here's the deal. In the destination partition there is a =+Sent folder that was created. However, when running a mboxutil -lx | grep uid | grep Sent I get the Sent folder that is on the original partition and not the new one. Could there be a conflict because a Sent mail folder was created in the new partition? If yes, what can I do to get around resolving that issue? Many thanks...
> I can kill the mboxutil jobs successfully, but for
> some odd reason it still doesn't work when I try to
> run the command. It's hanging up every time. what
> are the other ways for moving the folder from the
> source to its destination partition?
If it's hanging, then likely something has the sent folder locked.
Have you restarted the server, as I suggested earlier? If not, that folder is likely STILL locked.
>
> Here's the deal. In the destination partition there
> is a =+Sent folder that was created. However, when
> running a mboxutil -lx | grep uid | grep Sent I get
> the Sent folder that is on the original partition and
> not the new one. Could there be a conflict because a
> Sent mail folder was created in the new partition?
> If yes, what can I do to get around resolving that
> issue? Many thanks...
No, there is no confilict.
If restarting doesn't fix the hanging issue, then you can simply copy the contents of the old Sent directory to the new one, remove the old one, and run
reconstruct -r user/userid
for the user.
Thank you for your prompt response. My problems aren't solved however. I am dealing directly with a production server and I have no direct authority to restart the server, as you suggested in your previous replies. The only thing I can do is kill the occassional 'mboxutil' jobs that I attempt to run.
What I have noticed now is that any commands I attempt to run against that one problematic user/<userid> do not work. For example,
I tried, mboxutil -c user/<userid>/test to create a test folder and that freezes too.
>> If restarting doesn't fix the hanging issue, then you can simply copy the contents of the old Sent directory to the new one, remove the old one, and run
I tried, mboxutil -d user/<userid>/Sent (to remove the old folder, as you suggested) and that doesn't work because again it freezes.
When I tried to run similar commands on another test account, they all work very smoothly. Now I'm concerned that this particular user's mailbox may have gotten locked somehow. My question is, has that ever happened before and if the answer is yes, what can I do to remedy this issue without having to restart the messagin server.
Thanks in advance for your help.
Well, I'm afraid that indeed that mailbox is locked.
There is exactly ONE way to solve this. Restart.
As messages come in for that user, they may also hang. Eventually, this can cause all mail delivery for your entire server to stop.
Your user also may not be able to send mail out.
Again, there is only one way to handle this. Restart.
The sooner you do this, the better. Monitor your store/mboxlist directory for a buildup of log* files. More than 2 is a bad sign, and will cause the restart to take MUCH longer. Don't put this off. Waiting will make your pain greater. Eventually, your processes will grow, your disk will fill up, and you will have a disaster.
Hi,
I fully concur with Jay. Orphan database locks can happen when a program which locks a database page crashes (e.g. imapd process crashes, or mboxutil process crashes). The orphan database lock in this case can _only_ be removed with a restart of the entire store. During a restart the store process clears out any orphan locks and you are good to go.
Since locking is at a database page level, it is entirely possible that only one or a small number of folders are affected (not necessarily for the same account). This is why similar operations on other accounts work fine.
A restart is a quick operation - if you don't have the authority to restart the messaging server then I suggest you contact the person who does.
Regards,
Shane.
