Changes

Jump to: navigation, search

XELK-AN-008: How to use systemd on an Embedded system

177 bytes added, 13:30, 24 September 2019
no edit summary
This application note '''is not a complete systemd user's guide''' but collects some useful hints that can be used for getting familiar with systemd. There is a plenty of documentation and User's Guide available for systemd, but some simple example - that can be found here below - may simplify the systemd approach for beginners.
 
== Brief description ==
systemd manages not only services but many different objects called '''Unit'''. Unit are related to the resources that systemd can manage. Unit configurations are defined into the ''Unit files''.
 
Units categoris (identified by the file extension) are:
 
.service
.target
.socket
.device
.mount
.automount
.swap
.path
.timer
.snapshot
.slice
.scope
 
Major insteresting Units are '''services''' and '''targets'''. They will be analyzed in the following paragraphs.
== Architecture ==
The most used commands on a Linux embedded system are the commands used for: start a service, looking at logging, evalutate the boot time and configuring the network interface. In the following paragraphs, there are the related commands used for these tasks.
 
=== Manage services ===
root@imx6qxelk:~# systemctl unmask emergency
Removed /etc/systemd/system/emergency.service.
</pre>
 
==== From SystemV to systemd ====
 
===== start =====
 
Considering a SystemV <code>script</code> executing the ''start()'' function as in the following example:
<pre>
start() {
echo "Starting My Custom Service..."
/usr/bin/myservice -D
}
</pre>
 
The related command is executed in the custom service <code>/usr/bin/myservice</code> with the same '''-D''' parameter. It is possibile to use the <code>ExecStart=</code>:
 
<pre>
[Service]
ExecStart=/usr/bin/myservice -D
</pre>
 
===== restart =====
 
The same SystemV script may use special commands for restarting the service like <code>reboot()</code> function:
 
<pre>
reboot() {
echo "Reloading My Custom Service..."
/usr/bin/myservice reload
}
</pre>
 
which is equivalent to use <code>ExecReload=</code>:
 
<pre>
[Service]
ExecReload=/usr/bin/myservice reload
</pre>
 
===== stop =====
 
The <code>stop()</code> function in the script will become <code>ExecStop=</code>:
 
SystemV:
 
<pre>
stop() {
echo "Stopping My Custom Service..."
/usr/bin/myservice shutdown
}
</pre>
 
systemd:
 
<pre>
[Service]
ExecStop=/usr/bin/myservice shutdown
</pre>
== Services and targets ==systemd manages not only services but many different objects called '''Unit'''. Unit are related to the resources that systemd can manage. Unit configurations are defined into the ''Unit files''. Units categoris (identified by the file extension) are:  .service .target .socket .device .mount .automount .swap .path .timer .snapshot .slice .scope Major insteresting Units are '''services''' and '''targets'''. They will be analyzed in the following paragraphs. === Targets ===
Targets are used by systemd for having a synchronization mechanism between different services at boot time or during runtime changes.
All services linked to a ''target'' are linked to the modification to the same target. These can be seen in a similar way of SystemV ''runlevels'' with many other added functionalities.
==== Target and runlevels ====
Here below there is a list of power on/off targets and related SystemV runlevels:
</pre>
==== Active targets ====
It is possible to display all active targets with:
systemctl set-default multi-user
=== Unit files ===
For a complete information on '''Unit''' please look to the [https://www.freedesktop.org/software/systemd/man/systemd.unit.html documentation page]
Here below you can find an extract for the main used topics and configuration descriptions.
==== Location Path ====
Units are configured by ''systemd'' using configuration files that can be found in different directories. Each of them has different priority and behaviour:
{| class="wikitable"|-! Path !! Description|-| /lib/systemd/system || This directory stores a copy of configuration files. This is the default destination for new installed configuration file. Typically files in this directory should not be modified by the user.|- | /etc/systemd/system || This is the directory where to store a new ''Unit'' or to modify an existing one. The files present in this directory have the highest priority.|- | /run/systemd/system || The files present in this directory have higher priority only respect the ones on <code>/lib/systemd/system</code>. Systemd creates these configuration files dinamically at runtime; modification on this directory can be used for testing a runtime behaviour for a ''Unit'' but all modifications will be lost at next boot.|}
==== [Unit] section options ====
This section is used for defining the metadata and relations between different ''Unit''
|}
==== [Install] section options ====
This section is optional but is commonly used for defining a ''Unit'' behaviour when it will be executed during ''enable'' or ''disable'' commands.
|}
==== Specific sections ====
Some ''Unit'' have specific sections based on their characteristic. The most important is the section '''Service''' related to the Unit <code>.service</code>
Please find more information at the [https://www.freedesktop.org/software/systemd/man/systemd.service.html# documentation page]
===== [Service] section =====
Used for providing configurations for the ''services''.
====== Type ======
<code>Type=</code> uses one of the (main) following values:
! Value !! Description
|-
| simple: || Default configuration for a service when specified <code>ExecStarts=</code>
|-
| forking: || the process will call a <code>fork()</code> when starts causing the father to exit. This informs systemd that the process is still alive even if the father has been terminated.
|-
| oneshot: || the process has a very short execution time and then systemd should wait for its termination before continuing with other Units. this is the default configuration if <code>ExecStarts=</code> is not specified.
|-
| dbus: || the Unit will acquire the name on the D-Bus. systemd will continue to process the other Units
|-
| notify: || the service will notify when completely initialized. systemd will wait for the notification before continuing with the following Units
|-
| idle: || the service will not be executed until all active jobs are dispatched.
|}
====== Other options ======
{| class="wikitable"
===== Basic settings =====
After {| class="wikitable"|-! Parameter !! Description|-| After || The executed command (''iperf3'') requires the network interface to be already active, so we use <code>After</code> for this purpose.|- | Restart || This is configured with ''0'' for disabling the service after it has been run.|- | RestartSec || time sleep before restarting the service; default value is 100ms.|- | User || configures the ''user'' or ''group'' used for executing the service.|- | ExecStart || command to be executed when the service will be started (in our case ''iperf3'').|- | WantedBy || defines which target is used related to the service started. |}
===== running a service =====
systemctl enable myservice
 
=== From SystemV to systemd ===
 
==== start ====
 
Considering a SystemV <code>script</code> executing the ''start()'' function as in the following example:
<pre>
start() {
echo "Starting My Custom Service..."
/usr/bin/myservice -D
}
</pre>
 
The related command is executed in the custom service <code>/usr/bin/myservice</code> with the same '''-D''' parameter. It is possibile to use the <code>ExecStart=</code>:
 
<pre>
[Service]
ExecStart=/usr/bin/myservice -D
</pre>
 
==== restart ====
 
The same SystemV script may use special commands for restarting the service like <code>reboot()</code> function:
 
<pre>
reboot() {
echo "Reloading My Custom Service..."
/usr/bin/myservice reload
}
</pre>
 
which is equivalent to use <code>ExecReload=</code>:
 
<pre>
[Service]
ExecReload=/usr/bin/myservice reload
</pre>
 
==== stop ====
 
The <code>stop()</code> function in the script will become <code>ExecStop=</code>:
 
SystemV:
 
<pre>
stop() {
echo "Stopping My Custom Service..."
/usr/bin/myservice shutdown
}
</pre>
 
systemd:
 
<pre>
[Service]
ExecStop=/usr/bin/myservice shutdown
</pre>
8,154
edits

Navigation menu