Users cannot start/stop a VPS: Difference between revisions
Created page with "There are two possible issues here, often both occurring at the same time. =VPS information is not available from the DTC panel= If you get an error in the 'Installation' tab o..." |
Astropoint (talk | contribs) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
There are | There are a few possible issues here, and multiple can often occur at the same time. | ||
=VPS information is not available from the DTC panel= | =VPS information is not available from the DTC panel= | ||
| Line 8: | Line 8: | ||
On some nodes, DTC-Xen is set up to respawn if it is killed (as opposed to being controlled by the init.d script). In this case, just ''kill'' any dtc-soap-server process (''kill -9'' if that fails) and hopefully it will respawn with a new process ID. | On some nodes, DTC-Xen is set up to respawn if it is killed (as opposed to being controlled by the init.d script). In this case, just ''kill'' any dtc-soap-server process (''kill -9'' if that fails) and hopefully it will respawn with a new process ID. | ||
node00004 is an oddity at the moment and the SOAP client needs to be run manually in a screen. Make sure any old processes are killed, then run ''/usr/sbin/dtc-soap-server.original'' as root | |||
=xm does not work= | =xm does not work= | ||
| Line 14: | Line 16: | ||
If this fails, the chances are that something is wrong with xend, the xen domain daemon. The primary cause is simply that the disk is full, so type ''df -h'' to check this is the case. The biggest cause of this is massive log files in ''/var/log'' so check these out my sorting by size (''ls --sort=size -h | head'') and deleting if necessary. It's worth noting that the system logger has a handle on these files so you will probably need to restart the logger to really free up the space. Try ''/etc/init.d/rsyslogd restart''. | If this fails, the chances are that something is wrong with xend, the xen domain daemon. The primary cause is simply that the disk is full, so type ''df -h'' to check this is the case. The biggest cause of this is massive log files in ''/var/log'' so check these out my sorting by size (''ls --sort=size -h | head'') and deleting if necessary. It's worth noting that the system logger has a handle on these files so you will probably need to restart the logger to really free up the space. Try ''/etc/init.d/rsyslogd restart''. | ||
=Device is mounted in a guest domain= | |||
Sometimes Xen can get confused and think something's mounted when it's not. [http://old-list-archives.xen.org/archives/html/xen-users/2008-09/msg00502.html This page] has a few useful tips. | |||
Latest revision as of 16:43, 23 January 2017
There are a few possible issues here, and multiple can often occur at the same time.
VPS information is not available from the DTC panel
If you get an error in the 'Installation' tab of a VPS saying that there is a SSL timeout, it likely means that the DTC-Xen daemon on the affected node is not running correctly.
Bring up a command line as root on that node and attempt to run /etc/init.d/dtc-xen restart. Hopefully this will bring up the DTC SOAP server. If this doesn't work, you might need to kill any existing processes so type ps aux | grep soap and kill' the offending process.
On some nodes, DTC-Xen is set up to respawn if it is killed (as opposed to being controlled by the init.d script). In this case, just kill any dtc-soap-server process (kill -9 if that fails) and hopefully it will respawn with a new process ID.
node00004 is an oddity at the moment and the SOAP client needs to be run manually in a screen. Make sure any old processes are killed, then run /usr/sbin/dtc-soap-server.original as root
xm does not work
Try typing xm list to see if this will bring up a list of running VPSs. Do wait at least 30 seconds as this can sometimes be slow.
If this fails, the chances are that something is wrong with xend, the xen domain daemon. The primary cause is simply that the disk is full, so type df -h to check this is the case. The biggest cause of this is massive log files in /var/log so check these out my sorting by size (ls --sort=size -h | head) and deleting if necessary. It's worth noting that the system logger has a handle on these files so you will probably need to restart the logger to really free up the space. Try /etc/init.d/rsyslogd restart.
Device is mounted in a guest domain
Sometimes Xen can get confused and think something's mounted when it's not. This page has a few useful tips.