Skip to main content

Manual and Automatic Reboots

Manual Reboots

Memset provides an online facility to reboot both miniservers and full servers via the Memset control panel. The server reboot page is linked to from two locations:

  1. Account Summary page under the Tools section
  2. Manage page for each server.

From either location all servers in the account can be rebooted by choosing the desired server from the Server name drop down list.

An email address must be supplied in the “Contact email address” field before the re-boot request can be submitted. This is so that a confirmation email can be sent to the submitted address once the server has been rebooted. The reboot confirmation email will not be sent until the reboot has been initiated.

A reboot will occur around 5 minutes after the Reboot Now button has been clicked.

Automated Reboots

The default monitoring which Memset uses for all servers is to ping them every few minutes. If the server fails to respond to the ping twice, or around 10 minutes, then it assumed offline and rebooted. In the event that the server continues to fail to respond after the re-boot then an engineer will be alerted and the server be manually inspected.

In either case an email is also sent to the account Technical Contact notifying them that an auto-reboot occurred.

More information on Memset server monitoring options can be found in the Monitoring section of the documentation:

Why did my server get rebooted?

A very common cause of auto-reboots is the installation of a firewall that disallows ping packets. The monitoring system is unable to distinguish whether the failure to respond to the ping is due to a firewall or a crash so the default is to reboot the server.

In order to avoid this occurring the following Memset IP addresses should be allowed full TCP and UDP access to the server during installation of a firewall or similar security software:


In the event that the server crashed and was auto-rebooted the monitoring system does not record any information on the cause of the crash. This is because we only monitor the external symptoms of a crash i.e. the failure to respond to a ping request. For this reason the support team is unable to supply any information regarding the cause of the crash without logging into the server. The support team will only be able to do this upon request and if the server has a Managed support package.

The reason for a crash is usually (but not always) recorded in the system logs of the server. If the server has Managed Support then a Memset engineer will be happy to review the system logs and see if any useful information can be found.

This information is generally contained in the kernel messages log which can be found at:


This log file can be viewed with the following command:

less /var/log/messages

For newer systemd based servers the following command will show the kernel log:


A further common cause of crashing is that the server exhausted all it's available system memory. Please refer to the following documentation for more information on this common issue:

It is frequently the case that a server in this problem situation can still be accessed via the MemShell service even when it is unavailable via normal means e.g. ssh. Please refer to the Memset MemShell documentation for more information which can be found here:

Why didn't my server get rebooted?

Servers have a huge number of possible way to crash. Some crashes will take offline all of the important services e.g. website, email, db etc, whilst still leaving the server able to respond to ping packets. As long as the server is responding to ping packets and only has Basic Monitoring then it will be considered online and will not be rebooted.

This situation can be avoided by upgrading to Advanced Monitoring as this tier of monitoring will check the individual statuses of http, mysql, smtp etc and not just the ping response of the server. If you would like to upgrade to Advanced Monitoring please send an email to the sales team at:

Last updated 27 June 2019, 15:08 GMT