Reboot a machine

Infrastructure

Under normal circumstances most machines reboot automatically when an update is required. Some machines need to be rebooted manually.

If machines are not rebooting automatically, there there may be a problem with the locking mechanism.

Rules of manual rebooting

Read this page first to see if any special cases apply to the type of machine you need to reboot.
Most machines in Production should be rebooted out of hours, and this is handled by those who are on call out of hours.
Some machines in Production may need to be rebooted in hours though, and machines in other environments can usually be rebooted in hours as well.
Do not reboot more than one machine of the same class at the same time.
When rebooting clustered applications (such as RabbitMQ) wait for the cluster to recover fully before rebooting the next machine.
If you are rebooting a machine in AWS (either out of hours or in hours) it’s advised to pair with the RE interruptible/on call person.

Rebooting guidance for AWS

If rebooting machines in AWS, extended reboot times may result in the relevant machine being terminated automatically. If this happens, a new machine will be created automatically.

There have been a few cases when a reboot in AWS has not come back successfully and RE will be able to help in these cases. It also means RE can investigate any problems so it doesn’t happen again and we have confidence in our ability to reboot machines in AWS.

There’s a section on rebooting cache machines in AWS.

Unattended upgrades

Machines are configured with automatic security updates which install security updates overnight. Sometimes these require a reboot in order to become active.

You can review the list of packages on machines (or classes of machines) with the following command. Logs of the previous runs can be found in /var/log/unattended-upgrades.

fab $environment all apt.packages_with_reboots

You will then need to decide whether to:

Reboot the machine
Silence the check until the next package requires update (fab $environment all apt.reset_reboot_needed)

Deciding whether to reboot or silence

This can be quite nuanced. Before you go ahead with any course of action, gather evidence and then ask in the #re-govuk Slack channel.

Find details of the update from the Ubuntu Security Notices.

Is it a remote or local exploit?
Is it a kernel update?
If it’s a shared library, are we using it (see below)?

There is a Fabric task to find all processes using a deprecated library:

fab $environment all vm.deprecated_library:dbus

Checking locking status

locksmith manages unattended reboots to ensure that systems are available. It is possible that a problem could occur where they can’t reboot automatically. The following commands assume you have correctly [set up your fabric scripts][setup-fabric-scripts].

$ fab <environment> all locksmith.status

If a lock is in place, it will detail which machine holds the lock.

You can remove it with:

$ fab <environment> -H <machine-name> locksmith.unlock:"<machine-name>"

Machines that are safe to reboot should then do so at the scheduled time.

Rebooting one machine

First check whether the machine is safe to reboot. This is stored in puppet in hieradata. For example, here is an example of a machine that cannot be safely rebooted. The default is safe_to_reboot::can_reboot: 'yes'.

If there is an incident which requires the rebooting of a machine otherwise marked as ‘no’, then it may be done provided any downstream effects of this reboot have been considered.

There is a Fabric task to schedule a machine for downtime in Nagios for 20 minutes and then reboot it:

fab $environment -H graphite-1.management vm.reboot

Note (Carrenza only)

There is a known issue whereby adding an extra disk using the LSI Logic Parallel (SCSI) controller to a VM causes the BIOS boot order to change, meaning that the system disk cannot be found and the OS does not boot when the affected VM is restarted. See the manual entry on adding disks for more info.

Rebooting Cache machines in AWS

The cache machines run the router app which handles live user traffic. To safely reboot them without serving too many errors to users, we must remove them from the AWS load balancer target groups before rebooting:

Login to the AWS Console for the relevant environment (gds aws govuk-<environment>-<your-role> -l).
Find the Instance ID of the critical machine(s) (probably all 8 blue-cache machines)
Remove the machine from the following Target Groups:
1. cache-assets-origin
2. cache-www
3. cache-www-origin
SSH onto the machine (find this from the reboots required alert listing)
Check the traffic has reduced to only be the Smokey healthchecks now: tail -f /var/log/nginx/lb-access.log.
Run the vm.reboot fab script on your local machine like normal.
Re-add the machine to the above target groups.
Check the traffic is flowing from the load balancer with tail -f /var/log/nginx/lb-access.log again.

Rebooting MongoDB machines

You can see our MongoDB machines by running:

$ fab $environment puppet_class:mongodb::server hosts

All secondary Mongo machines will reboot overnight. If you don’t need to reboot the cluster right now, step the current primary down and allow it to reboot overnight:

$ fab $environment -H $hostname mongo.step_down_primary

The general approach for rebooting machines in a MongoDB cluster is:

Check cluster status with fab $environment -H $hostname mongo.status
Using fab $environment -H $hostname mongo.safe_reboot
- Reboot the secondaries
- Reboot the primary. The mongo.safe_reboot Fabric task automates stepping down the primary and waiting for the cluster to recover before rebooting.

Rebooting Redis machines

Unless there are urgent updates to apply, these machines should not be rebooted during working hours in production. Other services rely directly on particular Redis hosts and may error if they are unvailable.

Reboots of these machines, in the production environment, should be organised by On Call staff and search-api workers must be restarted (by re-deploying the latest release) after the reboot.

They may be rebooted in working hours in other environments, however you should notify colleagues before doing so as this may remove in-flight jobs that Sidekiq has added to the Redis queues but not yet processed.

Rebooting RabbitMQ machines

There’s a Fabric task to reboot all nodes in the RabbitMQ cluster, waiting for the cluster to recover before rebooting the next node.

Note

We have had a couple of incidents after running this script, so it should only be done in-hours and requires careful monitoring. See:

1) No non-idle RabbitMQ consumers - This required killing RabbitMQ processes to resolve.

2) Publishing API jobs became stuck - This required restarting Publishing API workers to resolve.

If there are problems with the cluster (eg, a partition has happened), the safe_reboot script will not reboot anything, and you’ll need to take manual action to resolve the problem.

Reboot the nodes in the cluster:

fab <environment> class:rabbitmq rabbitmq.safe_reboot

If any applications start alerting due to rabbitmq-1 being rebooted then either add a note here about how to make that application recover, or get the team responsible to make it point to the cluster.

Rebooting asset master and slave machines

Unless there are urgent updates to apply the master machine should not be rebooted in production during working hours - as the master machine is required for attachments to be uploaded.

The slave machines can be rebooted as they hold a copy of data and are resynced regularly.

Reboots of the master machine should be organised by On Call staff, for the production environment.

You may reboot the master machine in the staging environment during working hours however it is prudent to warn colleagues that uploading attachments will be unavailable during this period.

Rebooting router-backend machines

Router backend machines are instances of MongoDB machines and can be rebooted as per the MongoDB rebooting guidance.

Rebooting jumpbox machines

These machines are safe to reboot during the day. During the night they are involved in a data sync processes and rebooting could cause the data sync to fail.

Rebooting backend-lb machines (Carrenza only)

In order to safely reboot these machines you’ll need access to vCloud Director, in order to switch traffic away from backend-lb-1 before rebooting it - all traffic goes through this machine unless it fails.

Reboot backend-lb-2 and wait for it to recover.

fab -H backend-lb-2.backend vm.reboot

Doing this may trigger a PagerDuty alert and trigger 5xx errors on Fastly.

Find the IP addresses of backend-lb-1 and backend-lb-2 for the environment. They will be listed in this repo.
Use vCloud Director to update the NAT rule to point to backend-lb-2.
- The Nat rule will be in this repo.
- Go to “Administration”.
- Find 'GOV.UK Management’ in the list of vdcs and click on it
- Select the “edge gateway” tab, right click on it and select “edge gateway services”.
- Click the NAT tab.
- Find the rule corresponding to the rule defined in the vcloud-launcher file, and update the DNAT rules to point to the IP address of backend-lb-2 by clicking edit, and updating the “Translated (Internal) IP/range” field and click OK to save these rules.
Reboot backend-lb-1 and wait for it to recover

fab -H backend-lb-1.backend vm.reboot
Use vCloud Director to update the NAT rule to point back to the IP address of backend-lb-1.

Rebooting MySQL backup machines (Carrenza only)

The MySQL backup machines create a file during the backup process. If that file exists, the machine isn’t safe to reboot.

Check if the file exists:

fab <environment> -H mysql-backup-1.backend sdo:'test -e /var/lock/mysql-backup.lock'

If the file doesn’t exist (that command returns non-0), reboot the machine:
```
fab <environment> -H mysql-backup-1.backend vm.reboot
```

Rebooting MySQL master and slave machines (Carrenza only)

Unless there are urgent updates to apply, these machines should not be rebooted during working hours in production. Applications write to the masters and read from the slaves (with the exception of the slave within the Disaster Recovery environment).

Reboots of these machines, in the production environment, should be organised by On Call staff.

They may be rebooted in working hours in the staging environment, however you should notify colleagues before doing so.

Whitehall MySQL slave machines

The whitehall-mysql-slave-1 machine is used by the frontend component of Whitehall, so this’ll be impacted when rebooting. The other whitehall-mysql-slave machines are not used by Whitehall frontend.

Rebooting PostgreSQL primary and standby machines (Carrenza only)

Unless there are urgent updates to apply, these machines should not be rebooted in production during working hours. Applications read and write to the primary machines, and some applications (e.g. Bouncer) read from the standby machines (with the exception of the slave within the Disaster Recovery environment).