Kill transfer on new transfer tool

[sozotech]

Running WHM 11.44.0 (build 22) and I started a transfer which appeared to hang when viewing /usr/local/cpanel/bin/view_transfer as well as the web interface. So I killed all of the PID's that view_transfer showed but in the web interface it still shows the process is running in a PAUSED state. How can I clear this out because it won't let me start a new transfer until I do.

Thanks,
Eric

 

[iserversupport]

Try these commands you can find the PID's of process still running

ps -aux | grep pkgacct
ps-aux | grep restorepkg

 

[sozotech]

Try these commands you can find the PID's of process still running

ps -aux | grep pkgacct
ps-aux | grep restorepkg

This is using the new transfer tool. Regardless neither of these processes are running on the source or destination server. I see the session information is in /var/cpanel/transfer_sessions/. Should I just delete the directory for this session?

Best regards,
Eric

Best regards,
Eric

 

[cPanelMichael]

Hello

Please open a support ticket so we can take a closer look. You can post the ticket number here and we will update this thread with the outcome.

Thank you.

 

[cPanelNick]

We have added the ability to abort a in progress transfer with case 106025.

This functionality is currently scheduled to be published in the next minor release (11.44.2) and the next major release (11.46.0).

As 11.46.0 is currently scheduled to be published before then 11.44.2, is likely that 11.46.0 will available before the 11.44.2 maintenance release.

When an 11.46 build becomes available with this case, the change log will be here:
http://documentation.cpanel.net/display/ALD/11.46+Change+Log

When an 11.44 build becomes available with this case, the change log will be here:
http://documentation.cpanel.net/display/ALD/11.44+Change+Log

 

[calvomat]

I am running WHM 11.44.1 (build 17) and have the same problem with hang failed transfers.
In "Review Transfers and Restores" on the web interface I can see two transfers under RUNNING Sessions and one under PAUSING Sessions, and they are all stopped but there is no way to cancel them.

I understand that this will be fixed in 11.44.2, but how can I manually fix it in the meantime?

Thanks.
Matias

 

[cPanelMichael]

Hello

You can manually mark the transfer as completed using the following instructions:

1. Ensure the transfer is no longer running by clicking on the “View” option under "Sessions in Progress" for this transfer. In the new window, there will be a line that looks like this:

You may close this window and view the transfer on the command line: /usr/local/cpanel/bin/view_transfer 1054056copya201407021337529eG8A76iJY

Access your server via SSH and run that command (the transfer name will be different on your server):

/usr/local/cpanel/bin/view_transfer 1054056copya201407021337529eG8A76iJY

As an example, you might see output like this:

Transfer running with pid: 795
[795   ][MASTER     ]: Start Session
[795   ][MASTER     ]: Version: 1.9
[795   ][MASTER     ]: Queue “TRANSFER” items: 1
[795   ][MASTER     ]: Queue “RESTORE” items: 1
[795   ][MASTER     ]: Remote Host: 10.1.1.1
[797   ][TRANSFER:1 ]: Starting Account: “cptest”
[797   ][TRANSFER:1 ]: Account “cptest”: success
[797   ][TRANSFER:1 ]: Progress: 100%
[797   ][TRANSFER:1 ]: Child Complete
[ERROR ][MASTER     ]: Error: Cpanel::DBI::Mysql connect('','root',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at /usr/local/cpanel/Cpanel/MysqlUtils/Connect.pm line 42
[ERROR ][MASTER     ]: Error: Cpanel::DBI::Mysql connect('','root',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at /usr/local/cpanel/Cpanel/MysqlUtils/Connect.pm line 42

You will note that the master PID for this transfer is 795. If the process still exists, and the transfer has failed, then you can kill that process:

kill -9 795

2. The next step requires you to change the entry for this transfer in the whmxfer.sessions table in MySQL. Find the entry with the session ID for your migration. In the example we have been using, it's '1054056copya201407021337529eG8A76iJY.' It will look like this:

-bash-4.1# mysql -e "select * from whmxfer.sessions where sessionid='1054056copya201407021337529eG8A76iJY'"
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------+
| sessionid                            | initiator | pid  | version | target_host               | source_host | state | starttime           | endtime |
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------+
| 1054056copya201407021337529eG8A76iJY | copyacct  |  795 |     1.9 | hostname.server | 10.1.1.1 |    20 | 2014-07-02 08:37:52 | NULL    |
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------+

You will need to change the 'state' field to 100, and change the 'endtime' field from NULL to a time after the 'starttime' field:

-bash-4.1# mysql -e "update whmxfer.sessions set state='100', endtime='2014-07-02 09:37:52' where sessionid='1054056copya201407021337529eG8A76iJY'"

Thus, the output then looks like this:

-bash-4.1# mysql -e "select * from whmxfer.sessions where sessionid='1054056copya201407021337529eG8A76iJY'"
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------------------+
| sessionid                            | initiator | pid  | version | target_host               | source_host | state | starttime           | endtime             |
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------------------+
| 1054056copya201407021337529eG8A76iJY | copyacct  |  795 |     1.9 | hostname.server | 10.1.1.1  |   100 | 2014-07-02 08:37:52 | 2014-07-02 09:37:52 |
+--------------------------------------+-----------+------+---------+---------------------------+-------------+-------+---------------------+---------------------+

The transfer should then no longer appear under "Sessions in Progress."

Thank you.

 

[pdelteil]

As a matter of fact, more step are required to kill the transfer process.

You need to know the pid of all the current transfers (usually up to 5), in my case, I had to very big accounts being transfered (40 and 70 GBs each).

Some steps
1) Run the /usr/local/cpanel/bin/view_transfer 1054056copya20140XXXXXX
2) Find the transfers or restores still running.
3) Do kill -9 PID (where PID is the pid of all the processes still running)

Then do the update on the db, as mentioned above.

 

[cPanelNick]

As a matter of fact, more step are required to kill the transfer process.

You need to know the pid of all the current transfers (usually up to 5), in my case, I had to very big accounts being transfered (40 and 70 GBs each).

Some steps
1) Run the /usr/local/cpanel/bin/view_transfer 1054056copya20140XXXXXX
2) Find the transfers or restores still running.
3) Do kill -9 PID (where PID is the pid of all the processes still running)

Then do the update on the db, as mentioned above.

Killing the restore processes with signal 9 may corrupt account data and leave the account in a broken state (and may damage some of configuration data).

You should be able to safely terminate the TRANSFER processes and the main transfer_session process with kill -TERM, however the RESTORE processes need to complete to avoid potentially breaking the system.

 

[comma2007]

Hello,

this thread is very usefull and I used the Michael procedure to stop a stuck transfer.

I've now a stuck Restoring Account from a Backup Restoration, showing "Restoring Account" from 30 hours, even if the account is only 300 MB. The backup was not restored.

I checked the "/usr/local/cpanel/bin/backup_restore_manager state" :

# /usr/local/cpanel/bin/backup_restore_manager state
is_active=0
start [active]

======[ motori ]==============================
give_ip = 0
mail_config = 1
mysql = 1
subdomains = 1
restore_point = 2014-12-30

end [active]

start [pending]

end [pending]

start [completed]

end [completed]

reason = OK
result = 1

I tried all the "Actions" in the restoration page (Clear pending accounts, clear...) but nothing. I checked for running processes but nothing.

What can I do? I can't make any more restoration.

Thank you

 

[cPanelNick]

What can I do? I can't make any more restoration.

Thank you

Please open a ticket using the link in my signature and post the # here.

 

[comma2007]

I opened a ticket with ID 5909427

Thank you

 

[cPanelPeter]

Hello,

Just to update this thread, our analyst found that there was a stale file located at /var/cpanel/backups/queue/restore_queue.stor that was holding the information on the job, and not updating properly.

He moved that file to a backup location and then re-ran the backup_restore_manager state command, which solved the issue.

 

[Jared Long]

Hello,

My team and I have tried the steps above to kill a transfer stuck in the "aborting" state. The transfer in question shows as "completed" in WHM, but when you view the transfer it still says "aborting".

We also do not have a /var/cpanel/backups/queue/ directory, so that does not seem to be the solution. (please forgive my ignorance).

We are using WHM 11.48 build 4.

Can anyone point me to where the data for the session may still be stored?
Regards,
-Jared Long

 

[cPanelMichael]

Could you open a support ticket using the link in my signature so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[LUG]

Hello

We're facing the same situation described by Jared (Ticket 7374685)

Session is "ABORTING" for about 10 hours (i mean it's stuck). We tried all the workarounds from posts above but still unable do fix de issue.

Tnks

 

[Infopro]

Please feel free to open a ticket about this as mentioned above.

 

[cPanelMichael]

Hello

To update, per ticket number 7375633, it looks like the best explanation for why this happened is that MySQL was not running when it came time to update the "Aborting" status for the transfer progress as listed in Web Host Manager.

Thank you.