Changes

{{ImportantMessage|text=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 examples - 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.}}

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.

<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''.

==== wired Wired interface ====

==== wireless Wireless interface ====

For enabling the interface at boot time it is required to ''enable'' the service:

=== Logging with systemd =(<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-to-use-journalctl-to-view-and-manipulate-systemd-logs here] For example, to display the new log messages (similar to <code>tail -f /var/log/messages</code>) add the <code>-f</code> option

for displaying the new log messages (similar to With <code>tail -f /var/log/messagesp</code>)it's possible to set the log ''priority''

journalctl -pLEVEL

Where <code>LEVEL</code> can be the number or keyword of the following table (sorted from higher to lower priority). Specifying a priority will display messages marked with '''-p''' parameter is it possible to set the log ''severity'' :that priority or higher

! 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.:

journalctl -u ''<unit_name>'' for For displaying the log related to a specific ''Unit'', use the <code>-u</code> option, e.g.:

journalctl /dev/''<node_name>'' for For displaying the log related to a specific <code>/dev</code> device, just add it to the command line:

journalctl _UID=''<uid>'' for For displaying the log related to a user_id:user ID, use <code>_UID=</code> parameter

=== Analyze the boot time===

Boot time analysis is one of the most important and interesting activity for an emebedded 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.

==== time ====

==== blame ====

==== critical-chain ====The <code>critical-chain</code> parameter shows the startup process flow and the time consumed by each service. Here below a picture showing an example of critical path where the most time consuming task are displayed in red:

=== Targets ===

Targets are used by systemd for having a synchronization mechanism between different services at boot time or during runtime run-time changes.

==== Target and runlevels ====

On Into the following directory:

directory there is a list of services related to that target.

==== Active targets ====

=== Unit files ===

==== Location Path ====

{| class="wikitable"|-! Path !! Description|-| <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 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.|}

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 ====

==== [Install] section options ====

==== Specific sections ====

===== [Service] section =====

====== Type ======

| 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.

| 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 ======

=== Creating Putting it all together: create a new service ===

==== 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

Description=My Serviceiperf3 server mode

===== 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 Running a service =====

systemctl start myserviceiperf3

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>iperf3