Linux VPS Start Issue

Note: VE is virtual environment, refer as a VPS

Any operation on a VE gives "Cannot lock VE". How do I solve it?

VE is locked when some operation (backup, migration, start / stop, etc.) with this VE is in progress. You can determine which process is holding VE #101 using the following command on the hardware node:

# cat /vz/lock/101.lck

You can kill that process if needed. Make sure that the process is really killed. If there is no process with that PID on the node, just remove the lock file or rename is using mv /vz/lock/101.lck /vz/lock/101.lck.bk

~~~~~~~~~~~~~~~~~~~~~~~

VE starts but then just shuts down in a few minutes

You probably do not have a valid Virtuozzo license installed - it can be expired or number of VEs is exceeded. Please, check the output of 'vzlicview' command. The status of the license should be ACTIVE and 'used VE' should be not more than 've_total'.

Another possible reason - VE was created with so called class 1 (Light VE) and exceeds defined in license limits for a number of resources such as privvmpages, numproc, shmpages and other. You will find error messages like this in /var/log/messages file on a node:

VE 101 violates UB_PRIVVMPAGES

In this case it is recommended to change VE class to 2 (Unlimited VE) using

'vzctl set VE_ID --class 2 --save'.

~~~~~~~~~~~~~~~~~~~~~~~

VE starts but displays error "/bin/bash: no such file" or the like.

The owner of the VE could have removed some important package such as bash or glibc.

In this case you may recover VE private area using 'vzctl recover VEID'.

You may also have OS template the VE is abused on missed on hardware node, you may check it using 'vzpkgls VE_ID' and install missed OS template if it is needed.

The VE can also be compromised.

~~~~~~~~~~~~~~~~~~~~~~~

The VE starts but Segmentation fault occurs very soon after starting.

The VE can be compromised

VE can be compromised if its owner uses insecure or out-of-date software. To detect if VE #101 has any rootkits installed one can use the chkrootkit utility either inside the VE or (better) on the hardware node using -r /vz/root/101 parameter. There is also a way to determine which packages were modified on the VE:

- mount VE private area (it may be needed in case VE can not be started):

# vzctl mount 101

- check packages integrity:

# /usr/share/vzpkgtools/vzrpm/bin/rpm --root=/vz/root/101 --veid 101 -Va | egrep '^..5|missing'

This command shows the files that were modified or removed.

Path to the needed package manger (/usr/share/vzpkgtools/vzrpm/bin/rpm in the example above) may be different for different VEs (it depends on OS template of VE). You may check which package manager (PKGMAN) shoud be used in OS template in the file "/vz/template/$OSRELEASE/conf/$OSRELEASE.conf.$OSVERSION" for standard OS template or in the file "/vz/template/$OS/$RELEASE/$ARCH/config/os/default/package_manager" for EZ template, and use appropriate rpm in the command above.

For example, CentOS 4 uses 'PKGMAN=rpm43x86' so the path will be '/usr/share/vzpkgtools/vzrpm43/bin/rpm'

~~~~~~~~~~~~~~~~~~~~~~~

Follow the instructions from the corresponding article to repair a hacked VE.

There are two ways of restoring a VE which is hacked or cannot be started for some other reasons. Please make sure that you have created a full backup of the VE before applying any of the following solutions.

Solution #1:

# vzctl recover 101

This command will reinstall OS template and all application templates, which were previously installed on the VE. This action will make it possible to start the broken VE but it does not give any guarantee that all rootkits are removed, if any.

Solution #2:

# vzctl reinstall 101

This command will create a brand new VE on the same OS template as the broken one, install the same application templates into it and restore users' credentials. The contents of the old VE will be copied into /old directory.

~~~~~~~~~~~~~~~~~~~~~~~

The VE failed to start with the message like this:

ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0

vzquota : (warning) block_hard_limit [50100] <>

This error message means that VE exceeded its disk space quota and cannot be started because it is impossible to change system files during VE startup. Solution - increase diskspace (and probably inodes) alloted to VE using 'vzctl' utility:

# vzctl set VE_ID --diskspace BARRIER:LIMIT --save

#vzctl set VE_ID --diskinodes BARRIER:LIMIT --save

If increasing blocks and inodes limits does not help, try to re-init quota for this VE with:

# vzctl quotainit VE_ID

Then start VE

Exim : Message retry time not reached

What does the message retry time not reached [for any host] on the log mean? Why won't Exim try to deliver the message?

>>> That is not an error. It means exactly what it says. A previous attempt to deliver to that address failed with a temporary error, and Exim computed the earliest time at which to try again. This can apply to local as well as to remote deliveries.

For remote deliveries, each host (if there are several) has its own retry time.

If you are running on a dial-up host, the rest of this answer probably does not apply to you. If your host is permanently online.

Some MTAs have a retrying schedule for each message. Exim does not work like this.

Retry timing is normally host-based for remote deliveries and address-based for local deliveries. (There are some exceptions for certain kinds of remote failure - see Errors in outgoing SMTP in the manual.)

If a new message arrives for a failing address and the retry time has not yet arrived, Exim will log retry time not reached and leave the message on the queue, without attempting delivery.

Similarly, if a queue runner notices the message before the time to retry has arrived, it writes the same log entry. When the retry time has past, Exim attempts delivery at the next queue run. If you want to know when that will be, run the exinext utility on the address, for example:

exinext user@some.domain

You can suppress these messages on the log by including -retry_defer in the setting of log_selector.

You can force a delivery attempt on a specific message (overriding the retry time) by means of the -M option:

exim -M 10hCET-0000Bf-00

If you want to do this for the entire queue, use the -qf option.

Or Login to the server as root and try the following

/scripts/eximup --force

mv /etc/named.conf /etc/named.old

/scripts/rebuildnamedconf > /etc/named.conf

/scripts/fixndc

/etc/init.d/named restart

mail -vv nitinmartand@yahoo.co.in

VE is virtual environment, refer as a VPS

Note: VE is virtual environment, refer as a VPS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any operation on a VE gives "Cannot lock VE". How do I solve it?

# cat /vz/lock/101.lck

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VE starts but then just shuts down in a few minutes

You probably do not have a valid Virtuozzo license installed - it can be expired or number of VEs is exceeded. Please, check the output of 'vzlicview' command. The status of the license should be ACTIVE and 'used VE' should be not more than 've_total'.

VE 101 violates UB_PRIVVMPAGES

In this case it is recommended to change VE class to 2 (Unlimited VE) using

'vzctl set VE_ID --class 2 --save'.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VE starts but displays error "/bin/bash: no such file" or the like.

The owner of the VE could have removed some important package such as bash or glibc.
In this case you may recover VE private area using 'vzctl recover VEID'.

You may also have OS template the VE is abused on missed on hardware node, you may check it using 'vzpkgls VE_ID' and install missed OS template if it is needed.

The VE can also be compromised.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The VE starts but Segmentation fault occurs very soon after starting.
>>
The VE can be compromised

# vzctl mount 101

- check packages integrity:

# /usr/share/vzpkgtools/vzrpm/bin/rpm --root=/vz/root/101 --veid 101 -Va | egrep '^..5|missing'

This command shows the files that were modified or removed.
Path to the needed package manger (/usr/share/vzpkgtools/vzrpm/bin/rpm n the example above) may be different for different VEs (it depends on OS template of VE). You may check which package manager (PKGMAN) shoud be used in OS template in the file "/vz/template/$OSRELEASE/conf/$OSRELEASE.conf.$OSVERSION" for standard OS template or in the file "/vz/template/$OS/$RELEASE/$ARCH/config/os/default/package_manager" for EZ template, and use appropriate rpm in the command above.
For example, CentOS 4 uses 'PKGMAN=rpm43x86' so the path will be '/usr/share/vzpkgtools/vzrpm43/bin/rpm'

Follow the instructions from the corresponding article to repair a hacked VE.

# vzctl recover 101

# vzctl reinstall 101

The VE failed to start with the message like this:
ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0
vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]
vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]

# vzctl set VE_ID --diskspace BARRIER:LIMIT --save
vzctl set VE_ID --diskinodes BARRIER:LIMIT --save

If increasing blocks and inodes limits does not help, try to re-init quota for this VE with:

# vzctl quotainit VE_ID

Then start VE

.

Linux VPS Start Issue

Exim : Message retry time not reached

VE is virtual environment, refer as a VPS

Note: VE is virtual environment, refer as a VPS

Pages

Advertisement