In this article we will explore what systemd is, what problems it solves in the embedded systems field and how we can write a configuration file for our application.
We should start by saying that systemd is a service manager for Linux. By service, we mean any program running on the system. Systemd is compatible with SysV init scripts but offers advanced features such as:
the
starting of services in parallel
the
activation of services via socket or Dbus
the
managing of dependencies between different services
the
process isolation via cgroups
These features make it possible to simplify the configuration of services when booting an embedded system as well as allowing precise control over each individual service.
Consider for example a GUI application that during its operation needs to spawn other processes, such as a music player. In a normal system these processes have their own lifetime with respect to the program that spawned them. So, in order to ensure that the GUI application is fully stopped, it is necessary to kill all the processes that the GUI can spawn.
With systemd of this is necessary, since the processes spawned by the GUI are part of the same systemd service. Therefore, all that is required is to stop the GUI service, after which systemd will know which processes must be stopped.
Service configuration
Each service is described by a configuration file, which has a format very similar to INI files.
The simplest file consists of 3 sections: Unit, Service and Install.
[Unit]
It contains the basic information about the service. The most important fields of this section are:
Description:
a line describing the service.
Wants:
a list of services required for this service. If your program uses
socket or dbus activation, systemd automatically manages
dependencies and this field is not required.
After:
systemd
will wait for the services contained in this field to start before
starting this process. This field can also be omitted if activation
via socket or dbus is being used.
[Service]
This section specifies which file should be executed and how it will be executed. The most important fields are:
ExecStart:
the absolute
path
of the executable file.
Environment:
it is used to set the environment variables for the process. For
example:
Environment=EGLFS_HIDE_CURSOR=1
“POINTERCAL_FILE=/path/with spaces/pointercal”
Note that if
the variable contains spaces, the
name of the variable must also be placed in quotation mark.
Type:
it is used by systemd to understand which process is the “main
process”. It is useful when there are daemons that fork a few
times before starting; conversely, it is not particularly useful in
the case of a single application to be launched. Just set it to
simple.
Restart:
it configures how and when the service must be started. For embedded
systems that must always be on, the recommended value is always.
SuccessExitStatus:
a list of signals or numbers (other than 0) that indicate correct
termination of the program.
Multiple forks are widely used to create daemons from the shell. The documentation in this regard is very detailed.
[Install]
This section is useful for deciding when a service should be enabled or disabled. In systemd jargon, a service is enabled if it is started automatically at boot; this is usually the intended behaviour for embedded systems. In short:
[Install]
WantedBy=multi-user.targetComplete example
Here is a complete example of a configuration file for a GUI application to be started at boot.
[Unit]
Description=Description for myprogram
Wants=rpcbind.service
After=rpcbind.service
[Service]
Environment=“MY_ENV_VAR=/some/path/to/file with space.ini”
ExecStart=/usr/local/myprogram
Type=simple
[Install]
WantedBy=multi-user.targetThis brings the article to a close. For further information I suggest you read the systemd documentation and the variables guide of the configuration files.