Changes

Jump to: navigation, search

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

2,355 bytes added, 16:06, 9 November 2020
no edit summary
{{AppliesToAxelEsatta}}
{{AppliesToAxelLite}}
{{AppliesToAXEL Lite AN}}
{{AppliesToSMARX AN}}
{{AppliesToSBCX}}
{{AppliesToSBC Axel AN}}
{{InfoBoxBottom}}
systemd is a ''System and Service Manager'' which has enough different settings and configuration from SystemV(SysV) which was used on all XELK BSPs up to [[Axel_Embedded_Linux_Kit_(XELK)#XELK_3.0.0|XELK 3.0.0]].
{{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 Architecture ==systemd manages not only services but many different objects called '''Unit'''Here below, a picture (from [https://en.wikipedia. Unit are related to org/wiki/Systemd#Core_components_and_libraries wikipedia]) showing the resources that main systemd can manage. Unit configurations are defined into the ''Unit files''components: [[File: Systemd_components.png]]
Units categoris (identified by the file extension) are:== Configuring systemd ==
.The most used commands on a Linux embedded system are the commands used for: start a service .target .socket .device .mount .automount .swap .path .timer .snapshot .slice , looking at logging, evalutate the boot time and configuring the network interface.scope
Major insteresting Units are '''services''' and '''targets'''. They will be analyzed in In the following paragraphs, there are the related commands used for these tasks.
== Services = Manage services ===
<code>systemctl</code> is the main command line utility and primary tool to manage 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:
systemctl -t service --all
=== Other useful = service commands ====
Starting a service from userspace:
systemctl disable ''<service_name>''
==== systemctl mask a service ====
There is a third level for stopping a service other than ''stop'' and ''disable'': it is the command <code>mask</code>.
It stops the service and it will not possible to start it again using ''start''.Using <code>systemctl</code> it is possbile to ''mask/unmask'' a service:
<pre>
</pre>
== Targets == Migrating from SystemV to systemd ====
Targets are used by systemd for having a synchronization mechanism between different services at boot time or during runtime changes.===== start =====
They can be used for set 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 system custom service <code>/usr/bin/myservice</code> with the same '''-D''' parameter. It is possibile to a new state.use the <code>ExecStart=</code>:
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.<pre>[Service]ExecStart=/usr/bin/myservice -D</pre>
=== Target and runlevels == restart =====
Here below there is a list of power onThe same SystemV script may use special commands for restarting the service like <code>reboot()</off targets and related SystemV runlevelscode> function:
{| class="wikitable"<pre>|-! Description !! SystemV reboot(runlevel) !! systemd (target){|-| System halt || 0 || runlevel0 echo "Reloading My Custom Service.target, poweroff.target|-| Single user mode || 1, s, single || runlevel1.target, rescue.target"|- /usr/bin/myservice reload| Multi user || 2 || runlevel2.target, multi-user.target}|-| Multi user with network || 3 || runlevel3.target, multi-user.target|-| Experimental || 4 || runlevel4.target, multi-user.target|-| Multi user with network, graphical mode || 5 || runlevel5.target, graphical.target|-| Reboot || 6 || runlevel6.target, reboot.target|}</pre>
which is equivalent to use <code>multi-userExecReload=</code> target can be identified as the <code>runlevel 3</code>.:
On the <pre>[Service]ExecReload=/usr/bin/myservice reload</pre>
/etc/systemd/system/''<target_name>''.target.wants===== stop =====
directory there is a list of services related to that target.The <code>stop()</code> function in the script will become <code>ExecStop=</code>:
For exampleSystemV:
<pre>
root@imx6qxelk:~# ls /etc/systemd/system/multi-user.target.wants/stop() {atd.service busybox-syslog.service gpuconfig echo "Stopping My Custom Service.service ofono.service systemd-networkd.service"avahi-daemon.service connman.service mytest.service psplash-quit.service systemd-resolved.service/usr/bin/myservice shutdownbusybox-klogd.service crond.service ntpdate.service remote-fs.target}
</pre>
=== Active targets ===systemd:
It is possible to display all active targets with:<pre>[Service]ExecStop=/usr/bin/myservice shutdown</pre>
=== Configuring the network systemctl -t targetinterfaces===
Changing a targetOne of the most systemd configuration used is the '''Network configuration'''.
systemctl isolate graphical==== Wired interface ====systemd uses a slightly different configuration mechanism than SystemV. The configuration file is the following one with an example of configuration:
The actual target is shown with: /etc/systemd/network/eth0.network
systemctl get-default<pre>[Match]Name=eth0
Changing # Prevent the default target:interface loading if the kernel boots from nfsKernelCommandLine=!nfsroot
systemctl set-default multi-user[Network]Address=192.168.0.120Gateway=192.168.0.254DNS=192.168.0.1#DNS=8.8.8.8
== Unit files ==For a complete information on '''Unit''' please look to the [https:<//www.freedesktop.org/software/systemd/man/systemd.unit.html documentation page]pre>
Here below you can find an extract for the main used topics and configuration descriptions.'''Note:'''
=== Location Path ===The DNS is used only if the <code>systemd-resolved</code> service is enabled and the <code>/etc/resolv.conf</code> has a symbolic link to <code>/run/systemd/resolve/stub-resolv.conf</code>
Units are configured by ''<pre>ln -sf /run/systemd'' using configuration files that can be found in different directories/resolve/stub-resolv. Each of them has different priority and behaviour:conf /etc/resolv.conf</pre>
/lib/systemd/system==== Wireless interface ====
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.===== wpa_supplicant =====wpa_supplicant provides different services on systemd:
* <code>wpa_supplicant.service</code> uses D-Bus, recommended with the ''NetworkManager''* <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/systemdwpa_supplicant/wpa_supplicant-interface.conf</systemcode>
This For enabling the interface at boot time it is the directory where required to store a new ''Unitenable'' or to modify an existing one. The files present in this directory have the highest priority.service:
/run/systemd/systemsystemctl enable wpa_supplicant@interface
The files present in this directory have higher priority only respect the ones on <code>/lib/systemd/system</code>. Systemd creates these ===== wlan 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.example =====
=== [Unit] section options ===Assuming ''wlan0'' as the wireless interface name, the configuration file examples are the following one:
This section is used for defining the metadata and relations between different ''Unit'' /etc/systemd/network/wlan0.network
Please find below the main properties description:<pre>[Match]Name=wlan0[Network]# Uncomment for DHCP#DHCP=yesAddress=192.168.1.120Gateway=192.168.1.254DNS=8.8.8.8
{| class="wikitable"|-! Property !! Function|-| Description=: || Name and function|-| Documentation=: || URI for the documentationvv|-| Requires=: || List of ''Units'' dependencies. For 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 executed anyway. this is the recommended method to be used.|-| BindsTo=: || Similar to ''Requires'' but it does a Stop for the ''Unit'' when the listed ''Unit'' are terminated.|-| Before=: || The ''Unit'' listed will not be executed until this ''Unit'' will not change to ''started''. This is used for an order of Units executions.|-| After=: || The ''Unit'' listed 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''.|}</pre>
=== [Install] section options === /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
This section is optional but is commonly used for defining a ''Unit'' behaviour when it will be executed during ''enable'' or ''disable'' commands.<pre>ctrl_interface=/var/run/wpa_supplicanteapol_version=1ap_scan=1fast_reauth=1
network={| class ssid="SSID1" psk="wikitablepassword1"|- priority=1! Property !! Function}network={|- ssid="SSID2"| WantedBy psk=: || This is similar to the <code>Wants"password2" priority=2}</codepre> on ''[Unit]'' section but allows to mantain the top ''Unit'' more ''clean''.
When For automatically creating the ''Unit'' will be enablednetwork configuration, a directory on <code>/etc/systemd/system</code> will the following command can be created with the ''Unit'' name adding <code>.wants</code> to the name. Inside this directoty a symbolic link to the ''Unit'' is created.used:
Example: wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
* current Then, the service should be enabled on the ''Unitwlan0'' has interface for let systemd to start it using the (just) created configuration file <code>WantedBy=multi-user.target</code> * a directory <code>/etc/systemd/system/multiwpa_supplicant-user.targetwlan0.wantsconf</code> will be created * the symbolic link to the ''Unit'' will be created inside the new directory* 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=: || When the ''Unit'' is enabled, also the listed Units are enabled too.|} systemctl enable wpa_supplicant@wlan0
=== Specific sections =Logging with systemd (<code>journalctl</code>) ==
Some systemd has its own logging process called <code>journal</code> avoiding to start the ''Unitsyslog'' have specific sections based on their characteristicdaemon. The most important For the status information it is the section '''Service''' related possible to the Unit use <code>.servicejournalctl</code>.
Please find more information at the <code>journalctl</code> ha many command line switches, to customize its behavior and filter log data (a good reference can be found [https://www.freedesktopdigitalocean.orgcom/softwarecommunity/systemd/mantutorials/how-to-use-journalctl-to-view-and-manipulate-systemd.service.html# documentation page-logs here]
==== [Service] section ====For example, to display the new log messages (similar to <code>tail -f /var/log/messages</code>) add the <code>-f</code> option
Used for providing configurations for With <code>-p</code> it's possible to set the log ''servicespriority''.
===== Type ===== journalctl -p LEVEL
Where <code>Type=LEVEL</code> uses one can be the number or keyword of the following table (mainsorted from higher to lower priority) following values:. Specifying a priority will display messages marked with that priority or higher
{| class="wikitable"
|-
! Value !! DescriptionKeyword |-| 0 || emerg |-| 1 || alert
|-
| simple: 2|| Default configuration for a service when specified <code>ExecStarts=</code>crit
|-
| forking: 3|| 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.err
|-
| oneshot: 4|| 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.warning
|-
| dbus: 5|| the Unit will acquire the name on the D-Bus. systemd will continue to process the other Unitsnotice
|-
| notify: 6|| the service will notify when completely initialized. systemd will wait for the notification before continuing with the following Unitsinfo
|-
| idle: 7|| the service will not be executed until all active jobs are dispatched.debug |} ===== Other options =====  ExecStarts=:  Specifiy the full path and parameters for executing a service. If preceded by a "-" this inform that the command failure can be accepted.  ExecStartsPre=: used for adding more commands to be executed before starting the main process. May be used multiple times specifying the complete path and command parameters.  ExecReload=: commands to be executed for reloading the service configuration.  ExecStop=: commands required for stopping the service. If missing, the service will be killed.  ExecStopPost=: commands to be executed after the service has been stopped..  RestartSec=: time to sleep (seconds) before restarting the service.  Restart=: restart conditions for systemd to be checked before restarting the service (if terminated). Can be set to "always","on-success", "on-failure", "on-abnormal", "on-abort", or "on-watchdog".   TimeoutSec=: time to sleep during ''start<time>'' or ''stop'' before considering the process failed on start or stop. Start and stop timeout User can be set with different values filter by arbitrary time limits using the <code>TimeoutStartSec=--since</code> nad e and <code>TimeoutStopSec=--until</code> === Creating a new service === For creating a new service options, which restrict the following file has entries displayed to be created:  /etc/systemd/system/''<service_name>''those after or before the given time, respectively. E.g.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]root@imx6qxelk:/home# journalctl --since "20 min ago" Description=My ServiceAfter=network-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Mon 2019-07-08 13:22:01 UTC.target--StartLimitIntervalSec=0Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[Service551]: [ 3157.796945] ERROR: v4l2 capture: slave not found!Type=simpleJul 08 13:11:54 imx6qxelk kernel[551]: [ 3157.801690] ERROR: v4l2 capture: slave not found!Restart=0Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!RestartSec=1User=rootExecStart=/usr/bin/iperf3 -sJul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157.859371] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[Install551]WantedBy=multi-user: [ 3157.target864406] ERROR: v4l2 capture: slave not found!
</pre>
===== Basic settings =====  After  The executed command (For displaying the log related to a specific ''iperf3Unit'') requires the network interface to be already active, so we use the <code>After-u</code> for this purposeoption, e.  Restart This is configured with ''0'' for disabling the service after it has been rung.  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() {root@imx6qxelk:/home# journalctl -u systemd-networkd echo "Starting My Custom Service-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Mon 2019-07-08 13:25:01 UTC..."--Jul 05 11:02:13 imx6qxelk systemd-networkd[572]: Enumeration completedJul 05 11:02:13 imx6qxelk systemd-networkd[572]: eth0: IPv6 enabled for interface: SuccessJul 05 11:02:15 imx6qxelk systemd-networkd[572]: eth0: Gained carrier /usr/bin/myservice Jul 05 11:02:16 imx6qxelk systemd-Dnetworkd[572]: eth0: Gained IPv6LL}Jul 05 11:02:29 imx6qxelk systemd-networkd[572]: eth0: Configured
</pre>
The For displaying the log related command is executed in the custom service to a specific <code>/usr/bin/myservicedev</code> with the same '''-D''' parameter. It is possibile device, just add it to use the <code>ExecStart=</code>command line:
<pre>
[Service]ExecStart=root@imx6qxelk:~# journalctl /usrdev/bin/myservice fb0-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Thu 2019-07-11 09:07:01 UTC. --DJun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: registered mxc display driver ldbJun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: using reserved memory region at 0x8e000000, size 2 MiBJun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: assigned reserved memory node splashscreenJun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: using memory region 0x8e000000 0x8e1fffff
</pre>
==== restart ==== The same SystemV script may For displaying the log related to a user ID, use special commands for restarting the service like <code>reboot()_UID=</code> function:parameter
<pre>
rebootroot@imx6qxelk:~# id messagebusuid=995(messagebus) gid=993(messagebus) groups=993(messagebus) { echo "Reloading My Custom Serviceroot@imx6qxelk:~# journalctl _UID=993-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Thu 2019-07-11 09:14:01 UTC.--Jul 10 14:42:48 imx6qxelk systemd-timesyncd[423]: Network configuration changed, trying to establish connection.Jul 10 14:43:02 imx6qxelk systemd-timesyncd[423]: Network configuration changed, trying to establish connection." /usr/bin/myservice reload}Jul 11 07:38:31 imx6qxelk systemd-timesyncd[423]: Synchronized to time server 216.239.35.8:123 (time3.google.com).
</pre>
which is equivalent to use <code>ExecReload=</code>:= 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 <precode>[Service]ExecReload=/usr/bin/myservice reloadsystemd-analyze</precode>to help in this (hard) task
==== stop ====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.
The <code>stop()</code> function in the script will become <code>ExecStop=systemd-analyze</code>provides a good level of boot time information for further optimizations:
SystemV:=== time ===
The <precode>stop() { echo "Stopping My Custom Service..." /usr/bin/myservice shutdown}time</pre> systemd: <pre>[Service]ExecStop=/usr/bin/myservice shutdown</precode>parameter gives the total amount of seconds used for starting the kernel and reaching the userspace.
== systemd-analyze ==
<code>systemd-analyze</code> provides a good level of boot time information for further optimizations:
 
=== time ===
<pre>
root@imx6qxelk:~# systemd-analyze time
=== blame ===
The <code>blame</code> parameter gives the list of started services and how long they took for starting:
 
<pre>
root@imx6qxelk:~# systemd-analyze 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:
 
[[File:Systemd-analyze-critical-chain.png|800px]]
== Logging 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 interesting Units are '''services''' and '''targets'''. They will be analyzed in the following paragraphs.
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>.=== Targets ===
journalctl Targets are used by systemd for having a synchronization mechanism between different services at boot time or during run-ftime changes.
They can be used for displaying set the system to a new log messages (similar to <code>tail -f /var/log/messages</code>)state.
journalctl -pAll 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.
with '''-p''' parameter ==== Target and runlevels ==== Here below there is it possible to set the log ''severity'' a list of power on/off targets and related SystemV runlevels:
{| class="wikitable"
|-
! Value Description !! Severity SystemV (runlevel) !! Keyword systemd (target)
|-
| 0 System halt || Emergency 0 || emerg runlevel0.target, poweroff.target
|-
| 1 Single user mode || Alert 1, s, single || alert runlevel1.target, rescue.target
|-
| 2Multi user || Critical 2 || crit runlevel2.target, multi-user.target
|-
| 3Multi user with network || Error 3 || err runlevel3.target, multi-user.target
|-
| 4Experimental || Warning 4 || warning runlevel4.target, multi-user.target
|-
| 5Multi user with network, graphical mode || Notice 5 || notice runlevel5.target, graphical.target
|-
| 6Reboot || Information || info |-| 7|| Debug 6 || debug runlevel6.target, reboot.target
|}
<code>multi-user</code> target can be identified as the <code>runlevel 3</code>. Into the following directory:   journalctl --since /etc/systemd/system/''<timetarget_name>''.target.wants
with different keywords likethere is a list of services related to that target. For example:
<pre>
root@imx6qxelk:~# ls /etc/systemd/system/home# journalctl multi--since "20 min ago" user.target.wants/atd.service busybox-syslog.service gpuconfig.service ofono.service systemd- Logs begin at Wed 2019networkd.serviceavahi-06daemon.service connman.service mytest.service psplash-26 13:22:41 UTC, end at Mon 2019-07quit.service systemd-08 13:22:01 UTCresolved. servicebusybox--Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157klogd.796945] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157service crond.801690] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel: ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157service ntpdate.859371] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157service remote-fs.864406] ERROR: v4l2 capture: slave not found!target
</pre>
==== Active targets ====
 
It is possible to display all active targets with:
 
systemctl -t target
 
Changing a target
 
systemctl isolate graphical
 
The actual target is shown with:
 
systemctl get-default
 
Changing the default target:
 
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 ====
journalctl -u Units are configured by ''<unit_name>systemd''using configuration files that can be found in different directories. Each of them has different priority and behaviour:
{| class="wikitable"|-! Path !! Description|-| <code>/lib/systemd/system</code> || This directory stores a copy of configuration files: this is the default destination for displaying new installed configuration file. Typically files in this directory should not be modified by the log related user.|-| <code>/etc/systemd/system</code> || This is the directory where to store a specific 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.|}
<pre>root@imx6qxelk:/home# journalctl -u systemd-networkd -- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Mon 2019-07-08 13:25:01 UTC. --Jul 05 11:02:13 imx6qxelk systemd-networkd==== [572Unit]: Enumeration completedJul 05 11:02:13 imx6qxelk systemd-networkd[572]: eth0: IPv6 enabled for interface: SuccessJul 05 11:02:15 imx6qxelk systemd-networkd[572]: eth0: Gained carrierJul 05 11:02:16 imx6qxelk systemd-networkd[572]: eth0: Gained IPv6LLJul 05 11:02:29 imx6qxelk systemd-networkd[572]: eth0: Configured</pre>section options ====
journalctl /dev/This section is used for defining the metadata and relations between different ''<node_name>Unit''
for displaying Please find below the log related to a specific <code>/dev</code> devicemain properties description:
<pre>{| class="wikitable"root@imx6qxelk|-! Property !! Function|-| Description=:~# journalctl /dev/fb0|| Name and function|-| Documentation=: || URI for the documentationvv|- Logs begin at Wed 2019| Requires=: || List of ''Units'' dependencies. For successfully executing this ''Unit'', all listed dependency should be activated without errors, otherwise this Unit return ''fail''.|-06-26 13| Wants=:22:41 UTC|| Similar to a ''Requires'' but weaker. If the ''Unit'' listed are not found or return fail, end at Thu 2019this ''Unit'' are executed anyway. this is the recommended method to be used.|-07| BindsTo=: || Similar to ''Requires'' but it does a Stop for the ''Unit'' when the listed ''Unit'' are terminated.|-11 09| Before=:07:01 UTC|| The ''Unit'' listed will not be executed until this ''Unit'' will not change to ''started''. This is used for an order of Units executions. -|-Jun 26 13| After=:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: registered mxc display driver ldb|| The ''Unit'' listed will be started before this ''Unit''. This is used for an order of Units executions.|-Jun 26 13| Conflicts=:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: using reserved memory region at 0x8e000000, size 2 MiB|| The ''Unit'' listed cannot be executed simultaneously to this ''Unit''.Jun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: assigned reserved memory node splashscreen|}Jun 26 13:22:41 imx6qxelk kernel: mxc_sdc_fb fb@0: using memory region 0x8e000000 0x8e1fffff</pre>==== [Install] section options ====
journalctl _UID=This section is optional but is commonly used for defining a ''<uid>Unit''behaviour when it will be executed during ''enable'' or ''disable'' commands.
for displaying {| class="wikitable"|-! Property !! Function|-| WantedBy=: || This is similar to the log related <code>Wants=</code> on ''[Unit]'' section but allows to a user_id:mantain the top ''Unit'' more ''clean''.
When the ''Unit'' will be enabled, a directory on <precode>root@imx6qxelk:~# id messagebusuid=995(messagebus) gid=993(messagebus) groups=993(messagebus)root@imx6qxelk:~# journalctl _UID=993-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Thu 2019-07-11 09:14:01 UTC. --Jul 10 14:42:48 imx6qxelk /etc/systemd-timesyncd[423]: Network configuration changed, trying to establish connection/system</code> will be created with the ''Unit'' name adding <code>.Jul 10 14:43:02 imx6qxelk systemd-timesyncd[423]: Network configuration changed, trying wants</code> to establish connectionthe name.Jul 11 07:38:31 imx6qxelk systemd-timesyncd[423]: Synchronized Inside this directoty a symbolic link to time server 216the ''Unit'' is created.239.35.8:123 (time3.google.com).</pre>
== Network Configuration ==Example:
One of * current ''Unit'' has <code>WantedBy=multi-user.target</code> * a directory <code>/etc/systemd/system/multi-user.target.wants</code> will be created * the most systemd configuration used is symbolic link to the ''Unit'Network configuration'will be created inside the new directory* disabling the ''Unit''the symbolic link is deleted and the relation is then removed.
|-| RequiredBy=: || This is similar to <code>WantedBy== wired interface ===systemd uses </code> but a dependency cause a slightly different configuration mechanism than SystemV''fail'' if not satisfied. The configuration file When the ''Unit'' is the following one enabled, a directory with an example of configurationadded ''.requires'' will be created|-| Also=:|| When the ''Unit'' is enabled, also the listed Units are enabled too.|}
/etc/systemd/network/eth0.network==== Specific sections ====
Some ''Unit'' have specific sections based on their characteristic. The most important is the section '''Service''' related to the Unit <precode>.service</code>[Match]Name=eth0
Please find more information at the [https://www.freedesktop.org/software/systemd/man/systemd.service.html# Prevent the interface loading if the kernel boots from nfsKernelCommandLine=!nfsrootdocumentation page]
===== [NetworkService]Addresssection ==192.168.0.120Gateway=192.168.0.254DNS=192.168.0.1#DNS=8.8.8.8
</pre>Used for providing configurations for the ''services''.
'''Note:'''====== Type ======
The DNS is used only if the <code>systemd-resolvedType=</code> service is enabled and uses one of the <code>/etc/resolv.conf</code> has a symbolic link to <code>/run/systemd/resolve/stub-resolv.conf</code>(main) following values:
{| class="wikitable"|-! Value !! Description|-| simple || Default configuration for a service when specified <code>ExecStarts=<pre/code>ln |-sf | forking || the process will call a <code>fork()</runcode> 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/resolve/stubwill continue to process the other Units|-resolv| notify || the service will notify when completely initialized.conf /etc/resolvsystemd will wait for the notification before continuing with the following Units|-| idle || the service will not be executed until all active jobs are dispatched.conf</pre>|}
=== wireless interface === Other options ======
{| class="wikitable"|-! Value !! Description|-| ExecStarts=: || Specifiy the full path and parameters for executing a service. If preceded by a "-" this inform that the command failure can be accepted.|-| ExecStartsPre=: || used for adding more commands to be executed before starting the main process. May be used multiple times specifying the complete path and command parameters.|-| ExecReload= wpa_supplicant : || commands to be executed for reloading the service configuration.|-| ExecStop=: || commands required for stopping the service. If missing, the service will be killed.|-| ExecStopPost=: || commands to be executed after the service has been stopped..|-| RestartSec=: || time to sleep (seconds) before restarting the service.|-| Restart=: || restart conditions for systemd to be checked before restarting the service (if terminated). Can be set to "always","on-success", "on-failure", "on-abnormal", "on-abort", or "on-watchdog". wpa_supplicant provides |-| TimeoutSec=: || 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 services on systemd:values using <code>TimeoutStartSec=</code> and <code>TimeoutStopSec=</code>|}
* <code>wpa_supplicant.== Putting it all together: create a new service</code> uses D-Bus, recommended with the ''NetworkManager''* <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 creating a new service the interface at boot time it is required following file has to ''enable'' the servicebe created:
systemctl enable wpa_supplicant@interface/etc/systemd/system/''<service_name>''.service
==== Configuration Service example ====
Assuming ''wlan0'' as the wireless interface name, the configuration file examples are The following paragraph shows how to create a new service called <code>iperf3</code> executing the following one:iperf3 command in server mode
/etc/systemd/networksystem/wlan0iperf3.networkservice
<pre>
[MatchUnit]NameDescription=wlan0iperf3 server modeAfter=network.targetStartLimitIntervalSec=0 [NetworkService]# Uncomment for DHCPType=simple#DHCPRestart=yes0AddressRestartSec=192.168.1.120GatewayUser=192.168.1.254rootDNSExecStart=8.8.8.8/usr/bin/iperf3 -s
[Install]
WantedBy=multi-user.target
</pre>
/etc/wpa_supplicant/wpa_supplicant-wlan0.conf=== Basic settings ===
{| class="wikitable"|-! Parameter !! Description|-| After || The executed command (''iperf3'') requires the network interface to be already active, so we use <precode>After</code> for this purpose.ctrl_interface=/var/|-| Restart || This is configured with ''0'' for disabling the service after it has been run/wpa_supplicant.|-| 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'').eapol_version=1|-ap_scan=1| WantedBy || defines which target is used related to the service started. fast_reauth=1|}
network={ ssid="SSID1" psk="password1" priorityRunning a service =1}network={ ssid="SSID2" psk="password2" priority=2}</pre>
For automatically creating Starting the network configuration, the following command can be usedservice from userspace:
wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.confsystemctl start iperf3
Then, Starting the service should be enabled on the ''wlan0'' interface for let systemd to start it using the (just) created configuration file <code>wpa_supplicant-wlan0.conf</code>at boot time:
systemctl enable wpa_supplicant@wlan0iperf3
U0007
Bureaucrats, dave_user, Administrators
8,154
edits
Retrieved from "https://wiki.dave.eu/index.php/Special:MobileDiff/8918...11468"

Navigation menu