How To Add Your Own Services to systemd For Easier Management

Linux servers are designed to run continuously; rather than manually starting important programs and leaving them in a tmux session, you should add them to systemd as a service that will start automatically at startup and restart if errors occur.

Work with Systemd and services

Systemd stores the configuration of services in two places. The first is / lib / systemd / system /, where you will find the configuration of many services on your system. Most software installations install services here. The second is / etc / systemd / system /, which replaces the / lib / systemd directory and is generally used to place services created by users. There is also / etc / systemd / users /, which performs services for individual connected users, such as retrieving mail.

Many of these services do not work all the time like nginx or MySQL would. You can print a list of services currently in use with:

service –status-all

Services with a “+” symbol are running and services with a “-” symbol are currently stopped. You can display more detailed information with:

nginx service status

Because the services run in the background, they do not log their output to your console, but log it to the systemd log. The “status” command will display the last lines of this log, but you can read it directly with:

journalctl -fn 50 -u nginx

This command prints the 50 most recent log entries (-n) of the nginx service (-u). It is configured to print everything and start at the bottom, following the new log entries as they are created (-f).

Of course, many applications still write most things in their access or error logs, so be sure to check them as well. The log keeps track of things recorded directly on the console, which can be useful for debugging your own services.

Simple service configuration

Systemd is used for many things on Linux; each object it manages is called a unit and has a corresponding “unit file” defining what it is. It can be simple services like nginx or MySQL, but it can also be mount points, devices, sockets and a lot of other stuff under the hood, all managed by systemd. Units can also be targets, used to control when other services will run (i.e. after network initialization).

For this use case, you will probably just want to configure your application as a basic service. To do this, you will need to create a new unit file, which you will want to put in / etc / systemd / system / and name it with a .service extension:

touch /etc/systemd/system/myapp.service

The unit files have a few different sections, but overall it will look like this:

[Unit]

Description = Example of service
After = network.target
StartLimitIntervalSec = 0

[Service]
Type = simple
Restart = always
RestartSec = 1
User = serviceuser
ExecStartPre =
ExecStart = / path / to / executable [options]
ExecStartPost
ExecStop =
ExecReload =

[Install]
WantedBy = multi-user.target

First, the [Unit] , which defines a set of metadata about the unit. The After = directive can be used to delay activation of the unit until another unit is started, such as a network or another service, such as mysql.service. = Where wants = directives. This section also configures the maximum number of times the unit will attempt to boot before systemd gives up completely; since you probably want him to keep trying, you can set it to 0 to disable this behavior.

Then comes the [Service] , specific to service unit files. This is where you will configure the Exec options. The user will run the service as a certain user. You can set this on your personal user account, root, or a custom service account. Just make sure the user has sufficient permissions to do their job.

There are a few different guidelines here for specifying which programs to run. ExecStartPre will run first, allowing you to perform any necessary configuration before the service actually starts. ExecStart is the main executable. ExecStartPost then runs, and ExecStop is executed when the service stops. ExecReload is a special directive and is used when you call “reload” instead of restarting. This allows you to reload at the time of configuration execution, provided that your application has the capacity.

Finally, the [Install] , which defines behavior more related to the way systemd manages the unit. This is most often used to specify the WantedBy = directive, which is used to tell systemd when to start your service, and creates symbolic links between targets and their dependent units. If you don’t know which target to use, multi-user.target will run the services on startup after everything is loaded.

Overall, the setup is pretty straightforward, and all you have to do is put your executable as an argument in the [Service] section. Once your service has been created, you will need to reload the systemctl daemon to update your changes:

sudo systemctl daemon-reload

And activate it (which will launch it at startup, depending on the configuration of the unit):

sudo systemctl activate myapp

And then start the service:

sudo service myapp start

The service should now be running in the background and you can check journalctl to watch its output. If it quits, systemd will restart it automatically and should run at startup with other services on your system.

If you need to restart your service, you can use:

sudo service myapp restart

Who will execute the directive ExecStop =, will stop the unit, then restart it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.