Changes

Jump to: navigation, search

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

11,339 bytes added, 16:06, 9 November 2020
no edit summary
{{AppliesToAxelEsatta}}
{{AppliesToAxelLite}}
{{AppliesToAXEL Lite AN}}
{{AppliesToSMARX AN}}
{{AppliesToSBCX}}
{{AppliesToSBC Axel AN}}
{{InfoBoxBottom}}
Starting from [[Axel_Embedded_Linux_Kit_(XELK)#XELK_4.0.0|XELK 4.0.0]] the root file system generated by NXP Yocto recipes produces a root file system using [https://www.freedesktop.org/wiki/Software/systemd/ systemd].
Systemd systemd is a ''System and Service Manager'' which has enough different settings and configuration from systemV 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== Brief description ==Systemd, differing from SystemV, manages This application note '''is not only services a complete systemd user's guide''' but many different objects called Unitcollects some useful hints that can be used for getting familiar with systemd. Unit are related to the resources There is a plenty of documentation and User's Guide available for systemd, but some simple examples - that systemd can manage. Unit configurations are defined into be found here below - may simplify the ''Unit files''systemd approach for beginners.}}
Units categoris == Architecture == Here below, a picture (identified by from [https://en.wikipedia.org/wiki/Systemd#Core_components_and_libraries wikipedia]) showing the file extension) main systemd components: [[File: Systemd_components.png]] == Configuring systemd == The most used commands on a Linux embedded system arethe 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.service .target .socket .device .mount .automount .swap .path .timer .snapshot .slice .scope
Major insteresting Units are '''=== Manage services''' and '''targets'''. They will be analyzed in the following paragraphs.===
== Services ==<code>systemctl</code> is the main command utility and primary tool 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
It is possible to display all services (including '''disabled''' and '''stopped''' services)with:
systemctl -t service --all
=== Other useful = service commands ====
Starting a service from userspace:
systemctl disable ''<service_name>''
== Targets ==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>root@imx6qxelk:~# systemctl mask emergencyCreated symlink /etc/systemd/system/emergency.service → /dev/null.</pre> If we will try to start it:<pre>root@imx6qxelk:~# systemctl start emergencyFailed to start emergency.service: Unit emergency.service is masked.</pre>
Targets are In this way, the service will not be used byt systemd for having as a synchronization point between different services at boot time or during runtime changes.dependency in the ''Unit''
They can be used for set the The reverse command is <code>unmask</code>:<pre>root@imx6qxelk:~# systemctl unmask emergencyRemoved /etc/systemd/system /emergency.service.</pre> ==== Migrating from SystemV to systemd ==== ===== start ===== Considering a new stateSystemV <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 =====
All services linked to a ''target'' are linked to The <code>stop()</code> function in the modification to the same target. These can be seen in a similar way of SystemV ''runlevels'' with many other added functionalities.script will become <code>ExecStop=</code>:
=== Target and runlevels ===SystemV:
Here below there is a list of power on<pre>stop() { echo "Stopping My Custom Service..." /off targets and related SystemV runlevels:usr/bin/myservice shutdown}</pre>
{| class="wikitable"|-! Description !! SystemV (runlevel) !! Systemd (target)|-| System halt || 0 || runlevel0.target, poweroff.target|-| Single user mode || 1, s, single || runlevel1.target, rescue.target|-| 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|}systemd:
<codepre>multi-user<[Service]ExecStop=/usr/bin/code> target can be identified as the <code>runlevel 3myservice shutdown</codepre>.
On === Configuring the network interfaces===
/etc/One of the most systemd/system/configuration used is the ''<target_name>'Network configuration'''.target.wants
directory there ==== Wired interface ====systemd uses a slightly different configuration mechanism than SystemV. The configuration file is a list the following one with an example of services related to that target.configuration:
For example: /etc/systemd/network/eth0.network
<pre>
root@imx6qxelk:~[Match]Name=eth0 # ls /etc/systemd/system/multi-userPrevent the interface loading if the kernel boots from nfsKernelCommandLine=!nfsroot [Network]Address=192.target168.wants/0.120atdGateway=192.service busybox-syslog168.service gpuconfig0.service ofono.service systemd-networkd.service254avahi-daemon.service connmanDNS=192.service mytest168.service psplash-quit0.service systemd-resolved.service1busybox-klogd#DNS=8.service crond8.service ntpdate8.service remote-fs.target8 
</pre>
=== Active targets ==='''Note:'''
It The DNS is possible used only if the <code>systemd-resolved</code> service is enabled and the <code>/etc/resolv.conf</code> has a symbolic link to display all active targtes with:<code>/run/systemd/resolve/stub-resolv.conf</code> <pre>ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf</pre>
systemctl -t target==== Wireless interface ====
Changing a target===== wpa_supplicant =====wpa_supplicant provides different services on systemd:
systemctl isolate graphical* <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/wpa_supplicant/wpa_supplicant-interface.conf</code>
The actual target For enabling the interface at boot time it is shown withrequired to ''enable'' the service:
systemctl get-defaultenable wpa_supplicant@interface
Changing the default target:===== wlan configuration example =====
systemctl set-default multi-userAssuming ''wlan0'' as the wireless interface name, the configuration file examples are the following one:
== Unit files ==For a complete information on '''Unit''' please look to the [https: //www.freedesktop.org/softwareetc/systemd/mannetwork/systemd.unitwlan0.html documentation page]network
Here below you can find an extract <pre>[Match]Name=wlan0[Network]# Uncomment for the main used topics and configuration descriptionsDHCP#DHCP=yesAddress=192.168.1.120Gateway=192.168.1.254DNS=8.8.8.8
=== Location Path ===</pre>
Units are configured by ''systemd'' using configuration files that can be found in different directories /etc/wpa_supplicant/wpa_supplicant-wlan0. Each of them has different priority and bahaviour:conf
* <codepre>ctrl_interface=/libvar/systemdrun/system</code>wpa_supplicanteapol_version=1ap_scan=1fast_reauth=1
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 the user.network={ ssid="SSID1" psk="password1" priority=1}network={ ssid="SSID2" psk="password2" priority=2}</pre>
* <code>/etc/systemd/system</code>For automatically creating the network configuration, the following command can be used:
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 wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
* <code>/run/Then, the service should be enabled on the ''wlan0'' interface for let systemd/system</code>The files present in this directory have higher priority only respect to start it using the ones on (just) created configuration file <code>/lib/systemd/systemwpa_supplicant-wlan0.conf</code>. Systemd creates these configuration files dinamcally 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 === systemctl enable wpa_supplicant@wlan0
This section is used for defining the metadata and relations between different ''Unit''== Logging with systemd (<code>journalctl</code>) ==
Please find below systemd has its own logging process called <code>journal</code> avoiding to start the main properties description:''syslog'' daemon. For the status information it is possible to use <code>journalctl</code>.
Description=<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]
Name and functionFor example, to display the new log messages (similar to <code>tail -f /var/log/messages</code>) add the <code>-f</code> option
Documentation=: With <code>-p</code> it's possible to set the log ''priority''
URI for the documentation journalctl -p LEVEL
Requires=: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 that priority or higher
List of {| class="wikitable"|-! Value !! Keyword |-| 0 || emerg |-| 1 || alert |-| 2|| crit |-| 3|| err |-| 4|| warning |-| 5|| notice |-| 6|| info |-| 7|| debug |}''Units'' dependencies. For succesfully executing this ''Unit<time>''User can filter by arbitrary time limits using the <code>--since</code> and <code>--until</code> options, all listed dependency should be activated without errorswhich restrict the entries displayed to those after or before the given time, otherwise this Unit return ''fail''respectively. E.g.:
Wants=<pre>root@imx6qxelk:/home# journalctl --since "20 min ago" -- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Mon 2019-07-08 13:22:01 UTC. --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]: [ 3157.796945] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157.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]: [ 3157.859371] ERROR: v4l2 capture: slave not found!Jul 08 13:11:54 imx6qxelk kernel[551]: [ 3157.864406] ERROR: v4l2 capture: slave not found!</pre>
Similar For displaying the log related to a specific ''RequiresUnit'' but weaker. If , use the ''Unit'' listed are not found or return fail<code>-u</code> option, this ''Unit'' are in any case executede. this is the recommended method to be usedg.:
<pre>root@imx6qxelk:/home# journalctl -u systemd-networkd BindsTo=-- 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 carrierJul 05 11:02:16 imx6qxelk systemd-networkd[572]: eth0: Gained IPv6LLJul 05 11:02:29 imx6qxelk systemd-networkd[572]: eth0:Configured</pre>
Similar For displaying the log related to ''Requires'' but a specific <code>/dev</code> device, just add it does a Sop for the ''Unit'' when to the listed ''Unit'' are terminated.command line:
Before=<pre>root@imx6qxelk:~# journalctl /dev/fb0-- Logs begin at Wed 2019-06-26 13:22:41 UTC, end at Thu 2019-07-11 09:07:01 UTC. --Jun 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>
The ''Unit'' listed will not be executed until this ''Unit'' will not change For displaying the log related to ''started''. This is used for an order of Units executions.a user ID, use <code>_UID=</code> parameter
After<pre>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 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.Jul 11 07:38:31 imx6qxelk systemd-timesyncd[423]: Synchronized to time server 216.239.35.8:123 (time3.google.com).</pre>
The ''Unit'' listed wile be started before this ''Unit''. This is used for an order of Units executions.== Analyze the boot time==
Conflicts=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 ''Unit'' listed cannot be executed simultaneously to this ''Unit''<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.
=== [Install] section ===<code>systemd-analyze</code> provides a good level of boot time information for further optimizations:
This section is optional but is comonly used for defining a ''Unit'' behaviour when it will be executed at boot === time with ''enable'' command.===
WantedBy=:The <code>time</code> parameter gives the total amount of seconds used for starting the kernel and reaching the userspace.
This is similar to the ''Wants<pre>root@imx6qxelk:~# systemd-analyze time Startup finished in 5.109s (kernel) + 4.771s (userspace) ='' on ''[Unit]'' section but allows to mantain the top ''Unit'' more ''clean''9.880s</pre>
Wwhen the ''Unit'' will be enabled, a directory on === blame ===The <code>/etc/systemd/systemblame</code> will be created with the ''Unit'' name adding <code>.wants</code> to the name. Inside this directotya symbolic link to parameter gives the ''Unit'' is created.list of started services and how long they took for starting:
Example<pre>root@imx6qxelk:~# systemd-analyze blame 3.608s dev-mmcblk0p2.device 547ms systemd-remount-fs.service 545ms systemd-vconsole-setup.service 544ms kmod-static-nodes.service 503ms systemd-udev-trigger.service 426ms systemd-journal-flush.service 407ms tmp.mount 371ms systemd-logind.service 327ms systemd-journald.service 317ms systemd-networkd.service 275ms systemd-timesyncd.service 257ms systemd-sysctl.service 204ms ofono.service 203ms systemd-modules-load.service 194ms sys-kernel-config.mount 188ms sys-kernel-debug.mount 177ms sshd.socket 161ms psplash-start.service 138ms systemd-random-seed.service 138ms sys-fs-fuse-connections.mount 129ms systemd-udevd.service 129ms systemd-update-utmp.service 128ms systemd-tmpfiles-setup-dev.service 124ms rc-local.service 98ms systemd-tmpfiles-setup.service 91ms psplash-quit.service 90ms systemd-resolved.service 89ms systemd-backlight@backlight:backlight.service 63ms dev-mmcblk0p1.device 41ms var-volatile.mount 33ms systemd-update-utmp-runlevel.service</pre>
* current ''Unit'' has <code>WantedBy=multi== critical-user.target</code> chain ===* a directory The <code>/etc/systemd/system/multicritical-user.target.wantschain</code> will be created * the symbolic link to the ''Unit'' will be created inside the new directoty* disabling the ''Unit'' parameter shows the symbolic link is deleted startup process flow and the relation is then removedtime consumed by each service.
RequiredBy=Here below a picture showing an example of critical path:
This is similar to ''WantedBy='' but a dependency cause a ''fail'' if not satisfied[[File:Systemd-analyze-critical-chain. When the ''Unit'' is enabled, a directory with added ''.requires'' will be createdpng|800px]]
Also=:= 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''.
When Units categoris (identified by the ''Unit'' is enabled, also the listed Units file extension) are enabled too.:
=== Specific sections === .service .target .socket .device .mount .automount .swap .path .timer .snapshot .slice .scope
Some Major interesting Units are ''Unit'services''' and '''targets''' have specific sections based on their characteristic. The most important is the section [Service] related to They will be analyzed in the Unit <code>following paragraphs.service</code>
Please find more information at the [https://www.freedesktop.org/software/systemd/man/systemd.service.html# documentation page]=== Targets ===
==== [Service] section ====Targets are used by systemd for having a synchronization mechanism between different services at boot time or during run-time changes.
Used for providing configurations They can be used for set the ''services''system to a new state.
===== Type =====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.
''Type='' should be set to :=== Target and runlevels ====
simpleHere below there is a list of power on/off targets and related SystemV runlevels:
Default configuration for a service when specified <code>ExecStarts{| class=</code>"wikitable"|-! Description !! SystemV (runlevel) !! systemd (target)|-| System halt || 0 || runlevel0.target, poweroff.target|-| Single user mode || 1, s, single || runlevel1.target, rescue.target|-| 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|}
forking:<code>multi-user</code> target can be identified as the <code>runlevel 3</code>.
Into 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.following directory:
oneshot:/etc/systemd/system/''<target_name>''.target.wants
the process has there is a very short execution time and then systemd should wait for its termination before continuing with other Units. this is the default configuration if ''ExecStarts='' is not specifiedlist of services related to that target.
dbusFor example:
the Unit will acquire the name on the D<pre>root@imx6qxelk:~# ls /etc/systemd/system/multi-user.target.wants/atd.service busybox-syslog.service gpuconfig.service ofono.service systemd-networkd.serviceavahi-daemon.service connman.service mytest.service psplash-Busquit. service systemd will continue to process the other Units-resolved.servicebusybox-klogd.service crond.service ntpdate.service remote-fs.target</pre>
notify:==== Active targets ====
the service will notify when completely initialized. Systemd will wait for the notification before continuing It is possible to display all active targets with the following Units:
idle:systemctl -t target
the service will not be executed until all active jobs are dispatched.Changing a target
===== Other options ===== systemctl isolate graphical
ExecStarts=The actual target is shown with:
Specifiy the full path and parameters for executing a service. If preceded by a " systemctl get-" this inform that the command failure can be accepted.default
ExecStartsPre=Changing the default target:
Può essere utilizzata per fornire comandi aggiuntivi che dovrebbero essere eseguiti prima del processo principale. Può essere usato multiple volte, deve specificare il percorso completo del comando e può essere usato anche qui il " systemctl set-" per tollerare errori.default multi-user
ExecReload=== Unit files ===For a complete information on '''Unit''' please look to the [https://www.freedesktop.org/software/systemd/man/systemd.unit.html documentation page]
commands to be executed Here below you can find an extract for reloading the service main used topics and configurationdescriptions.
ExecStop=:=== Location Path ====
commands required for stopping the service. If missing, the service will Units are configured by ''systemd'' using configuration files that can be killedfound in different directories.Each of them has different priority and behaviour:
ExecStopPost{| 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.|}
commands to be executed after the service has been stopped..==== [Unit] section options ====
RestartSec=:This section is used for defining the metadata and relations between different ''Unit''
time to sleep (seconds) before restarting Please find below the service.main properties description:
Restart{| 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''.|}
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". ==== [Install] section options ====
TimeoutSec=:This section is optional but is commonly used for defining a ''Unit'' behaviour when it will be executed during ''enable'' or ''disable'' commands.
time {| class="wikitable"|-! Property !! Function|-| WantedBy=: || This is similar to the <code>Wants=</code> on ''[Unit]'' section but allows to sleep during mantain the top ''startUnit'' or more ''stopclean'' 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>
When the ''Unit'' will be enabled, a directory on <code>/etc/systemd/system</code> will be created with the ''Unit'' name adding <code>.wants</code> to the name. Inside this directoty a symbolic link to the ''Unit'' is created.
== 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 systemt 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.
systemd uses |-| RequiredBy=: || This is similar to <code>WantedBy=</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 symbloic 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 === 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, recommende with the ''NetworkManager''* <code>wpa_supplicant@interface.service</code> uses the interface name (like ''wlan0'') as parameter ansd 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 start 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 The following paragraph shows how to create a configuration file example are 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 netwrok 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 sercice should be enabled on the ''wlan0'' interface for instructing systemd to start itusing the (just) created configuration file <code>wpa_supplicant-wlan0.conf</code>service 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/8900...11468"

Navigation menu