Since Ubuntu 15.04 Vivid Vervet the Systemd daemon manager was integrated into Ubuntu as a replacement for Upstart.
We are not going to enter the debate of whether it was a good or bad decision of Canonical to adopt systemd, but knowing that now with Ubuntu 16.04 there are many programs that use systemd to manage their demons, it was necessary to write a small
tutorial on how to create services in Ubuntu 16.04 with systemd
.
Without going any further, when we published the article on
how to create a seedbox with Deluge
or
how to install Tiny Tiny RSS
, in both tutorials a service was created that we configured with systemd. For this reason, it
is important to know the basics to create our own services and configure them correctly
.
What is a demon?
Let's start by trying to explain
what a demon
is intuitively and without going into great technicalities so that all users can address it.
We can define a demon as a process that works in the background and is capable of self-management, without the user having to interact with it.
In Debian operating systems and their derivatives such as Ubuntu, we have as a demon manager the so-called
systemd
.
How to create services in Ubuntu 16.04 with systemd.
First of all we must know the unit files, which are used to configure the services.
Unit files are text files that contain the different instructions and are housed by default in the path
/etc/systemd/system/
.
Basics about unit files, what they are and what they are for.
The names of the unit files are defined by a
unit_name
(unit name)
and
type_extension
(extension type)
. To understand this better we will propose an example name that will be
midemonio.service
.
Here we differentiate on the one hand
midemonio
as the
unit_name
and on the other hand we have that the
type_extension
is
.service
.
As
unit_name
we can choose a name that will help us identify the devil, but as
type_extension
we can only choose from twelve possibilities according to the functionality of the demon:
-
.service
-
.target
-
.automount
-
.device
-
.mount
-
.path
-
.scope
-
.slice
-
.snapshot
-
.socket
-
.swap
-
.timer
In this tutorial, as we intend to create a service, we will work only with the extension type
.service
.
In addition, there may be folders that accompany the unit files to add additional configurations. We are not going to cover this aspect in this tutorial, but it is good to name it so that we know that this possibility exists. In case of doubt you can always consult
additional documentation
of the unit files
(in English)
.
Creating the unit file to configure the service.
First we must create the unit file with its corresponding
unit_name
and
type_extension
, I will create the unit file
ejemplo.service
with the commands:
sudo touch /etc/systemd/system/ejemplo.service
sudo chmod 664 /etc/systemd/system/ejemplo.service
sudo nano /etc/systemd/system/ejemplo.service
As contents of the unit file pego:
[Unit]
Description=servicio de ejemplo
After=network.target mysql.service
[Service]
User=www-data
ExecStart=/ruta/script/demonio
Restart=on-failure
[Install]
WantedBy=multi-user.target
I think the content of the unit file is self-explanatory, but still we will be commenting on the different parts and options.
We see that the file is divided into three parts:
-
[Unit]
: This section establishes the generic options that do not depend on the type of extension.
-
[Service]
: This section sets out the specific options for the type of extension chosen. As in our example it is
type_extension
of type
.service
, this section is called
[Service]
. On the other hand, if it were of the
.socket
type, this section would be called
[Socket]
and so on with the rest of the extension types.
-
[Install]
: Contains information about the installation of the service that affects the execution of the
systemctl enable
and
systemctl disable
that we will explain later.
The most important unit file options are:
-
The
After
directive, which sets the order in which the different unit files are executed. There is also the
Before
directive that does the opposite. In our case we see that
ejemplo.service
will run after having run
network.target
and
mysql.service
.
-
The
User
directive sets the user under which the daemon script will run. You can also set the group with the
Group
directive. In our case, the demon script will run under the
www-data
user.
-
The
ExecStart
directive sets the script or command to execute.
This is a simple unit file that serves as an example, but to consult all the available options, you can consult the official manual page
systemd.service (5)
(in English)
.
Manage the service created with the systemctl command.
We only have to know the
systemctl
command that allows us to manage systemd. With our service
ejemplo.service
already created, we have to incorporate it into the system boot sequence with the command:
sudo systemctl enable ejemplo.service
We also have the
systemctl disable ejemplo.service
command to remove the service from the boot sequence. With the
systemctl daemon-reload
command
systemctl daemon-reload
restart the systemd process and it is used when we add or delete a service.
To start the service we use the command:
sudo systemctl start ejemplo.service
In the same way we can:
-
Stop the service:
sudo systemctl stop ejemplo.service
-
Restart the service:
sudo systemctl restart ejemplo.service
-
Get service status information:
sudo systemctl status ejemplo.service
Let's not forget that this guide is intended as a small introduction that serves as a contact for the creation of services with systemd, since a book would be needed to deal with the issue in greater depth. I hope that from now on it will not be a nightmare to create services in Ubuntu with systemd.
