Changes

Jump to: navigation, search

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

683 bytes added, 20:58, 24 September 2019
review
=== Manage services ===
<code>systemctl</code> is the main command utility and primary tool fo for managing the systemd daemons/services such as ''start, restart, stop, enable, disable, reload & status''.
It is possible to display all '''started''' services with the following userspace command:
</pre>
==== From Migrating from SystemV to systemd ====
===== start =====
One of the most systemd configuration used is the '''Network configuration'''.
==== wired Wired interface ====
systemd uses a slightly different configuration mechanism than SystemV. The configuration file is the following one with an example of configuration:
</pre>
==== wireless Wireless interface ====
===== wpa_supplicant =====
* <code>wpa_supplicant@interface.service</code> uses the interface name (like ''wlan0'') as parameter 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 ''enable'' the service:
systemctl enable wpa_supplicant@interface
systemctl enable wpa_supplicant@wlan0
=== Logging with systemd (<code>journalctl</code>) ===
systemd has its own logging process called <code>journal</code> avoiding to start the ''syslog'' daemon. For the status information it is possible to use <code>journalctl</code>.
<code>journalctl </code> ha many command line switches, to customize its behavior and filter log data (a good reference can be found [https://www.digitalocean.com/community/tutorials/how-fto-use-journalctl-to-view-and-manipulate-systemd-logs here]
for displaying For example, to display the new log messages (similar to <code>tail -f /var/log/messages</code>)add the <code>-f</code> option
journalctl With <code>-p</code> it's possible to set the log ''priority''
with ''' journalctl -p''' parameter is it possible LEVEL Where <code>LEVEL</code> can be the number or keyword of the following table (sorted from higher to set the log ''severity'' :lower priority). Specifying a priority will display messages marked with that priority or higher
{| class="wikitable"
|-
! Value !! Severity !! Keyword
|-
| 0 || Emergency || emerg
|-
| 1 || Alert || alert
|-
| 2|| Critical || crit
|-
| 3|| Error || err
|-
| 4|| Warning || warning
|-
| 5|| Notice || notice
|-
| 6|| Information || info
|-
| 7|| Debug || debug |}  journalctl --since ''<time>'' with different keywords likeUser can filter by arbitrary time limits using the <code>--since</code> and <code>--until</code> options, which restrict the entries displayed to those after or before the given time, respectively. E.g.:
<pre>
</pre>
journalctl -u ''<unit_name>'' for For displaying the log related to a specific ''Unit'', use the <code>-u</code> option, e.g.:
<pre>
</pre>
journalctl /dev/''<node_name>'' for For displaying the log related to a specific <code>/dev</code> device, just add it to the command line:
<pre>
</pre>
journalctl _UID=''<uid>'' for For displaying the log related to a user_id:user ID, use <code>_UID=</code> parameter
<pre>
=== Analyze the boot time===
Boot time analysis is one of the most important and interesting activity for an embedded system. : systemd provide an userspace command called <code>systemd-analyze</code>.to help in this (hard) task
The <code>systemd-analyze </code> command list how many services are running on the system and how long they took for starting at the last boot.
<code>systemd-analyze</code> provides a good level of boot time information for further optimizations:
.scope
Major insteresting interesting 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 run-time changes.
They can be used for set the system to a new state.
<code>multi-user</code> target can be identified as the <code>runlevel 3</code>.
On Into the following directory:
/etc/systemd/system/''<target_name>''.target.wants
directory there is a list of services related to that target.
For example:
! Path !! Description
|-
| <code>/lib/systemd/system </code> || This directory stores a copy of configuration files. This : this is the default destination for new installed configuration file. Typically files in this directory should not be modified by the user.
|-
| <code>/etc/systemd/system </code> || 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.
|-
| <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 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.
|}
|}
=== Creating Putting it all together: create a new service ===
For creating a new service the following file has to be created:
==== Service example ====
The following paragraph shows how to create a new service called '''myservice''' <code>iperf3</code> executing a the iperf3 command (in our case ''iperf3''):server mode
/etc/systemd/system/myserviceiperf3.service
<pre>
[Unit]
Description=My Serviceiperf3 server mode
After=network.target
StartLimitIntervalSec=0
|}
===== running Running a service =====
Starting the service from userspace:
systemctl start myserviceiperf3
Starting the service at boot time:
systemctl enable myserviceiperf3
731
edits

Navigation menu