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:

• Open your Cloud 66 Dashboard, and click the application in question
• Click ⚙ Settings & Information in the right-hand panel
• Click the Application Updates tab
• If you see an update named Server Process Manager then your application is still using bluepill. If you do not see it, your application is already using systemd. (See below for instructions on how to migrate to systemd.)

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.

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.

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:

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:
   • Puma
   • Thin
   • Unicorn
3. Set your application(s) to migrate (NOTE that this will require admin perms on the stack)
   • EITHER via web Dashboard: click ⚙ Settings & Information in the right-hand panel, then click the Application Updates tab, then apply the Server Process Manager update (if that update is not available, your app is already using systemd)
   • OR use 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.