Managing processes with systemd

Overview

By default Cloud 66 uses systemd to monitor and manage processes on all new servers. It is automatically installed on all servers provisioned through Cloud 66.

The only exception to this is for some legacy servers deployed before June 2020. These servers may use bluepill. If you need help migrating from bluepill please see our separate (legacy) guide.

Using systemd

You can use systemd to manually control processes on your servers using the command-line interface. If you are familiar with Ubuntu or other Linux variants you should recognise many of these commands.

When you add processes through the Cloud 66 web interface, they will will also use systemd but will be managed by Cloud 66.

We have documented some of the most common commands below, but please read the full man page for systemd if you need more detail. You might also read this excellent guide from DigitalOcean.

Process status

To get the status for all processes:

$ sudo systemctl 

To get the status for a specific process:

$ sudo systemctl status <application>.service 

An example of this in practice would be systemctl status nginx.service

Stop a service

To stop a service:

$ sudo systemctl stop <application>.service 

An example of this in practice would be systemctl stop nginx.service

Start a service

To start a service:

$ sudo systemctl start <application>.service 

An example of this in practice would be systemctl start nginx.service

Restart a service

Stops and then starts a service. Useful for refreshing a service after a configuration update:

$ sudo systemctl restart <application>.service 

An example of this in practice would be systemctl reload nginx.service

Reload a service

When supported, this reloads a service's config file without interrupting pending operations:

$ sudo systemctl reload <application>.service 

An example of this in practice would be systemctl reload nginx.service

Check if a service is running

Check if a service is currently running (active):

$ sudo systemctl is-active <application>.service 

An example of this in practice would be systemctl is-active nginx.service

Set a service to start at bootup

To set a service to start whenever the server is booted:

$ sudo systemctl enable <application>.service 

An example of this in practice would be systemctl enable nginx.service

Set a service to NOT start at bootup

To set a service to start whenever the server is booted:

$ sudo systemctl disable <application>.service 

An example of this in practice would be systemctl disable nginx.service

Process signals

The default process signals for systemd processes are:

Web reload signals

The generic web process restart (reload) signal is restart_signal: hup

For the default signals for specific web servers, click the links below:

• Puma
• Unicorn
• Thin

Non-Web processes

Specifying custom signals

If you'd like to specify custom process signals you can do this in your Manifest file.