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. You can check which process manager your application is using:

If you need help with 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.

Note

systemd does not require or support daemonized services. Unlike some other process managers (such as Bluepill), you should not add the `-d` flag to your systemd commands.

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

Migrating from Bluepill to systemd

If your servers are currently using Bluepill and you would like to transition to using systemd then please follow this checklist:

Before migrating from Bluepill to systemd you need to:

  1. Ensure none of your process initialization strings - including processes for custom web servers - use daemonization flags like -d or -daemonize. Using these flag with systemd will cause the process to terminate prematurely.
  2. Check and update any of your config files that enable daemonization. This is particularly relevant for users using custom web servers:
  3. Set your application(s) to migrate (NOTE that this will require admin perms on the stack)
    • Using the web Dashboard: Click ⚙Settings & Information in the right-hand panel, then click Switch to Systemd (in the Process Manager line)
    • Using the Toolbelt command: cx settings set -s APPLICATION_NAME migrate.bluepill.to.systemd true
  4. Redeploy your application

As always, we recommend testing your changes in a non-production environment before updating your live application.