Bureaucrats, dave_user, Administrators
8,142
edits
Changes
no edit summary
Systemd is a ''System and Service Manager'' which has enough different settings and configuration from systemV which was used on all XELK BSPs up to [[Axel_Embedded_Linux_Kit_(XELK)#XELK_3.0.0|XELK 3.0.0]].
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, differing from SystemV, 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:
systemctl -t service
It is possible to display all services (including '''disabled''' and '''stopped''' services)with:
systemctl -t service --all
== Targets ==
Targets are used byt by systemd for having a synchronization point mechanism between different services at boot time or during runtime changes.
They can be used for set the system to a new state.
=== Active targets ===
It is possible to display all active targtes targets with:
systemctl -t target
=== Location Path ===
Units are configured by ''systemd'' using configuration files that can be found in different directories. Each of them has different priority and bahaviourbehaviour:
* <code>/lib/systemd/system</code>
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 bye by the user.
* <code>/etc/systemd/system</code>
* <code>/run/systemd/system</code>
The files present in this directory have higher priority only respect the ones on <code>/lib/systemd/system</code>. Systemd creates these configuration files dinamcally 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''
Requires=:
List of ''Units'' dependencies. For succesfully successfully executing this ''Unit'', all listed dependency should be activated without errors, otherwise this Unit return ''fail''.
Wants=:
Similar to a ''Requires'' but weaker. If the ''Unit'' listed are not found or return fail, this ''Unit'' are in any case executedanyway. this is the recommended method to be used.
BindsTo=:
Similar to ''Requires'' but it does a Sop Stop for the ''Unit'' when the listed ''Unit'' are terminated.
Before=:
After=:
The ''Unit'' listed wile will be started before this ''Unit''. This is used for an order of Units executions.
Conflicts=
The ''Unit'' listed cannot be executed simultaneously to this ''Unit''.
=== [Install] section options ===
This section is optional but is comonly commonly used for defining a ''Unit'' behaviour when it will be executed at boot time with during ''enable'' commandor ''disable'' commands.
WantedBy=:
This is similar to the ''<code>Wants='' </code> on ''[Unit]'' section but allows to mantain the top ''Unit'' more ''clean''.
Example:
* current ''Unit'' has <code>WantedBy=multi-user.target</code>
* a directory <code>/etc/systemd/system/multi-user.target.wants</code> will be created
* the symbolic link to the ''Unit'' will be created inside the new directotydirectory
* disabling the ''Unit'' the symbolic link is deleted and the relation is then removed.
RequiredBy=:
This is similar to ''<code>WantedBy='' </code> but a dependency cause a ''fail'' if not satisfied. When the ''Unit'' is enabled, a directory with added ''.requires'' will be created
Also=:
=== 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]
===== Type =====
simple:
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:
ExecStartsPre=:
ExecReload=:
time to sleep during ''start'' or ''stop'' before considering the process failed on start or stop. Start and stop timeout can be set with different values using <code>TimeoutStartSec=</code> nad e <code>TimeoutStopSec=</code>
=== Creating a new service ===
For creating a new service the following file has to be created:
/etc/systemd/system/''<service_name>''.service
==== Service example ====
The following paragraph shows how to create a new service called '''myservice''' executing a command (in our case ''iperf3''):
/etc/systemd/system/myservice.service
<pre>
[Unit]
Description=My Service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=0
RestartSec=1
User=root
ExecStart=/usr/bin/iperf3 -s
[Install]
WantedBy=multi-user.target
</pre>
===== Basic settings =====
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 =====
Starting the service from userspace:
systemctl start myservice
Starting the service at boot time:
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>
== Network Configuration ==
One of the most systemt systemd configuration used is the '''Network configuration'''.
=== wired interface ===
'''Note:'''
The DNS is used only if the <code>systemd-resolved</code> service is enabled and the <code>/etc/resolv.conf</code> has a symbloic symbolic link to <code>/run/systemd/resolve/stub-resolv.conf</code>
<pre>
wpa_supplicant provides different services on systemd:
* <code>wpa_supplicant.service</code> uses D-Bus, recommende recommended with the ''NetworkManager''* <code>wpa_supplicant@interface.service</code> uses the interface name (like ''wlan0'') as parameter ansd and executes the wpa_supplicant daemon on that interface. The configuration file is <code>/etc/wpa_supplicant/wpa_supplicant-interface.conf</code>
For enabling the interface at boot time it is required to start ''enable'' the service
systemctl enable wpa_supplicant@interface
==== Configuration example ====
Assuming ''wlan0'' as the wireless interface name, the a configuration file example examples are the following one:
/etc/systemd/network/wlan0.network
</pre>
For automatically creating the netwrok network configuration, the following command can be used:
wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
Then, the sercice sergice should be enabled on the ''wlan0'' interface for instructing systemd to start itusing it using the (just) created configuration file <code>wpa_supplicant-wlan0.conf</code>:
systemctl enable wpa_supplicant@wlan0
