Table of Contents

Troubleshooting

Gandi provides you with a virtual server that you have ordered to fit your needs. Along with the advantages of a virtual dedicated server comes the responsibility of maintaining the system, however. Gandi cannot directly intervene in the administration of your server, or in correcting mistakes, debugging your code or providing assistance in the configuration of your server.

Problems and possible causes (using Gandi AI)

See:

Problems and possible causes (in expert mode)

See Troubleshooting a VPS in expert mode →

Common problems

You did not use the correct IP address for your server or the server does not exist behind this IP address. Check the status of your server in your administration page on the site. |

Input/ouput resources are collected by our Xen infrastructure, the use of your RAM have to be done from a program inside your virtuel server. More details : ici|

The kernel used by a server at boot is provided by the Xen infrastructure. Therefore kernel installed by package managment or even local compilation could not be used to boot a server. The Gandi team provide a set of kernel which you can associate with your kernel. See the next entry for choosing the kernel version.

The kernel used by a server at boot is associated with the 'main' disk. This disk is shown with a 'Boot disk' checked in the disk list in the server detail page in the hosting customer account. In the detailed page of this disk - after clicking on the disk name-, you will be able to choose a kernel version. After validating the operation, you will have to stop and start your virtual server.

This behavior is the result of the configuration of the file system about inotify options. These options allow the filesystem driver to warn the kernel about change in a directory that gsync watches. If the value of these options are to low, gsync will not backup completly the directory.

If your server is GandiAI please contact the support which will configure your server. If your server is in expert mode, please add these options to the /etc/sysctl.conf file : 

fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 8192
fs.inotify.max_queued_events = 16384

To apply change, add the entries in the /etc/sysctl.conf file and start the command : sysctl -p /etc/sysctl.conf

“Write barriers” are part of a mechanism used by file systems to guarantee that some kind of I/O request are send to the disk in a specific order. The current implementation is not efficient et is currently rewritten.Their performance impact is big for some rare case of corruption when the server is crashing at the wrong moment. LVM (“device-mapper”) and our current Xen setup does not support this feature.

When the file system is mounted it tries to detect the disk ability to handle this feature by setting a write barrier. The erreur (standard) return by the 'disk' subsystem is systematicaly registered in the request management system and generate this log entry as well as the “JBD: barrier-based sync failed on XXX” message. These messages can be ignored.

If the error message appears outside of the previous context (during the boot, when disk are attached to the server) or following another kind of message you should investigate further.

After april 2011, Gandi is using another storage infrastructure along the old one based on LVM. In the new model the main disk of your server does not contains any partition table anymore. The file system if created directly in the /dev/xvda1 disk.

If the file /proc/partitions does not contain /dev/xvda but only /dev/xvda1 you are on this new storage infrastructure. In this case simply resize the file system on /dev/xvda1 using : 

resize2fs /dev/xvda1

This comande may return an error telling you to checking the filesystem before resizing.

We mainly focus on LTS (Long Term Support) versions of Ubuntu, which have 5 years upstream support. Our local mirror of Ubuntu package tree is updated daily, so updates will be available the day after a release. Regarding new releases, we try to release an image in both architecture (32 and 64 bits) in both of our datacenters no more than one week after the official Ubuntu release. This gives us time to properly create the image and allow a few days for any major security discoveries. (RPM distributions can sometimes take longer.)

What you see is in fact the physical CPUs of the physical machine. To see your virtual CPU cores, we invite you to use the “top” command, then type on the “1” key in order to see separate CPU cores in top.