Skip to main content

Kill restore process in new cpanel

You may close this window and view the transfer on the command line: /usr/local/cpanel/bin/view_transfer 1071601843quick20141013154952IAZhRro
Access your server via SSH and run that command (the transfer name will be different on your server):
/usr/local/cpanel/bin/view_transfer 1071601843quick20141013154952IAZhRro
As an example, you might see output like this:
Transfer running with pid: paused
[795 ][MASTER ]: Start Session
[795 ][MASTER ]: Version: 1.9
You will note that the master PID for this transfer is xxx. If the process still exists, and the transfer has failed, then you can kill that process:
kill -9 xxx
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 ‘ 1071601843quick20141013154952IAZhRro .’ It will look like this:
mysql -e “select * from whmxfer.sessions where sessionid=’1071601843quick20141013152137YIVT7Ze'”
+————————————–+————–+——-+———+———————–+————-+——-+———————+———+
| sessionid | initiator | pid | version | target_host | source_host | state | starttime | endtime |
+————————————–+————–+——-+———+———————–+————-+——-+———————+———+
| 1071601843quick20141013152137YIVT7Ze | quickrestore | 21295 | 1.9 | vps1.insurancedxb.com | localhost | 50 | 2014-10-13 08:21:37 | 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:
mysql -e “update whmxfer.sessions set state=’100′, endtime=’2014-10-14 09:37:52′ where sessionid=’1071601843quick20141013152137YIVT7Ze'”
If you check it again then you will notice that process ended.
+————————————–+————–+——-+———+———————–+————-+——-+———————+———————+
| sessionid | initiator | pid | version | target_host | source_host | state | starttime | endtime |
+————————————–+————–+——-+———+———————–+————-+——-+———————+———————+
| 1071601843quick20141013152137YIVT7Ze | quickrestore | 21295 | 1.9 | vps1.insurancedxb.com | localhost | 100 | 2014-10-13 08:21:37 | 2014-10-14 09:37:52 |
+————————————–+————–+——-+———+———————–+————-+——-+———————+———————+

Comments

Post a Comment

Popular posts from this blog

WiFI connection

    root@kali:~# iw dev root@kali:~# ip link set wlan0 up root@kali:~# iw wlan0 scan root@kali:~# wpa_passphrase blackMOREOps >> /etc/wpa_supplicant.conf root@kali:~# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf root@kali:~# iw wlan0 link root@kali:~# dhclient wlan0 root@kali:~# ping 8.8.8.8 (Where wlan0 is wifi adapter and blackMOREOps is SSID) (Add Routing manually) root@kali:~# ip route add default via 10.0.0.138 dev wlan0    
Post a Comment
Read more

Modsecurity block rule for XMLRPC and wp-login attack

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134  <Locationmatch "/wp-login.php">  SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"  SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"  SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"  SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"  </Locationmatch>  SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000234  <Locationmatch "/xmlrpc.php">  SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000235,msg:'ip address blocked for 5 m...
Post a Comment
Read more

Apache tuning documentation

Apache bench marking ======================= Things or checklist to be considered before the test     CPU: avoid power-saving mode. cpufreq-set -g performance.     File descriptors: raise the limit to (at least) the number of concurrent connections you wish to handle, using ulimit -n in your shell, or setrlimit(RLIMIT_NOFILE) in your server. Beware, some systems forbid you to raise the limit, you might need to investigate a bit to find how to unlock it.     Disable the logs of your server (you do not want to lose time logging thousands of requests instead of answering them).     Raise /proc/sys/net/somaxconn to the number of concurrent connections you want to handle. To understand why this is necessary, read the technical report or the excellent paper Measuring the Capacity of a Web Server (Banga and Druschel, Usenix 97). More on the fascinating topic of the accept() queue can be found in accept()able Strategies for Im...
Post a Comment
Read more