Kill transfer on new transfer tool

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.

 

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

 

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:

Code:

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):

Code:

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

As an example, you might see output like this:

Code:

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:

Code:

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:

Code:

-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:

Code:

-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:

Code:

-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.

 

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.

 

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

 

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.

 

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.

 

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

 

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.