Difference between revisions of "XELK-AN-008: How to use systemd on an Embedded system"

From DAVE Developer's Wiki
Jump to: navigation, search
(Network Configuration)
Line 25: Line 25:
  
 
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]].
 
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 ==
 
== 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''.
+
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:
 
Units categoris (identified by the file extension) are:
Line 52: Line 54:
 
  systemctl -t service
 
  systemctl -t service
  
It is possible to display all services (including '''disabled''' and '''stopped''' services):
+
It is possible to display all services (including '''disabled''' and '''stopped''' services) with:
  
 
  systemctl -t service --all
 
  systemctl -t service --all
Line 76: Line 78:
 
== Targets ==
 
== Targets ==
  
Targets are used byt systemd for having a synchronization point between different services at boot time or during runtime changes.
+
Targets are used by systemd for having a synchronization mechanism between different services at boot time or during runtime changes.
  
 
They can be used for set the system to a new state.
 
They can be used for set the system to a new state.
Line 124: Line 126:
 
=== Active targets ===
 
=== Active targets ===
  
It is possible to display all active targtes with:
+
It is possible to display all active targets with:
  
 
  systemctl -t target
 
  systemctl -t target
Line 147: Line 149:
 
=== Location Path ===
 
=== Location Path ===
  
Units are configured by ''systemd'' using configuration files that can be found in different directories. Each of them has different priority and bahaviour:
+
Units are configured by ''systemd'' using configuration files that can be found in different directories. Each of them has different priority and behaviour:
  
 
* <code>/lib/systemd/system</code>
 
* <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 the user.
+
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>
 
* <code>/etc/systemd/system</code>
Line 158: Line 160:
  
 
* <code>/run/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 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.
+
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 ===
+
=== [Unit] section options ===
  
 
This section is used for defining the metadata and relations between different ''Unit''
 
This section is used for defining the metadata and relations between different ''Unit''
Line 176: Line 178:
 
  Requires=:
 
  Requires=:
  
List of ''Units'' dependencies. For succesfully executing this ''Unit'', all listed dependency should be activated without errors, otherwise this Unit return ''fail''.
+
List of ''Units'' dependencies. For successfully executing this ''Unit'', all listed dependency should be activated without errors, otherwise this Unit return ''fail''.
  
 
  Wants=:
 
  Wants=:
  
Similar to a ''Requires'' but weaker. If the ''Unit'' listed are not found or return fail, this ''Unit'' are in any case executed. this is the recommended method to be used.
+
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=:
 
  BindsTo=:
  
Similar to ''Requires'' but it does a Sop for the ''Unit'' when the listed ''Unit'' are terminated.
+
Similar to ''Requires'' but it does a Stop for the ''Unit'' when the listed ''Unit'' are terminated.
  
 
  Before=:
 
  Before=:
Line 192: Line 194:
 
  After=:
 
  After=:
  
The ''Unit'' listed wile be started before this ''Unit''. This is used for an order of Units executions.
+
The ''Unit'' listed will be started before this ''Unit''. This is used for an order of Units executions.
  
 
  Conflicts=
 
  Conflicts=
Line 198: Line 200:
 
The ''Unit'' listed cannot be executed simultaneously to this ''Unit''.
 
The ''Unit'' listed cannot be executed simultaneously to this ''Unit''.
  
=== [Install] section ===
+
=== [Install] section options ===
  
This section is optional but is comonly used for defining a ''Unit'' behaviour when it will be executed at boot time with ''enable'' command.
+
This section is optional but is commonly used for defining a ''Unit'' behaviour when it will be executed during ''enable'' or ''disable'' commands.
  
 
  WantedBy=:
 
  WantedBy=:
  
This is similar to the ''Wants='' on ''[Unit]'' section but allows to mantain the top ''Unit'' more ''clean''.
+
This is similar to the <code>Wants=</code> on ''[Unit]'' section but allows to mantain the top ''Unit'' more ''clean''.
  
Wwhen 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 directotya symbolic link  to the ''Unit'' is created.
+
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.
  
 
Example:
 
Example:
Line 212: Line 214:
 
* current ''Unit'' has <code>WantedBy=multi-user.target</code>  
 
* current ''Unit'' has <code>WantedBy=multi-user.target</code>  
 
* a directory <code>/etc/systemd/system/multi-user.target.wants</code> will be created  
 
* 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 directoty
+
* 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.
 
* disabling the ''Unit'' the symbolic link is deleted and the relation is then removed.
  
 
  RequiredBy=:
 
  RequiredBy=:
  
This is similar to ''WantedBy='' but a dependency cause a ''fail'' if not satisfied. When the ''Unit'' is enabled, a directory with added ''.requires'' will be created
+
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=:
 
  Also=:
Line 225: Line 227:
 
=== Specific sections ===
 
=== 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>
+
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]
 
Please find more information at the [https://www.freedesktop.org/software/systemd/man/systemd.service.html# documentation page]
Line 235: Line 237:
 
===== Type =====
 
===== Type =====
  
''Type='' should be set to :
+
<code>Type=</code> uses one of the (main) following values:
  
 
  simple:
 
  simple:
Line 247: Line 249:
 
  oneshot:
 
  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 ''ExecStarts='' is not specified.
+
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:
 
  dbus:
Line 269: Line 271:
 
  ExecStartsPre=:
 
  ExecStartsPre=:
  
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 "-" per tollerare errori.
+
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=:
 
  ExecReload=:
Line 295: Line 297:
 
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>
 
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 ==
 
== Network Configuration ==
  
One of the most systemt configuration used is the '''Network configuration'''.
+
One of the most systemd configuration used is the '''Network configuration'''.
  
 
=== wired interface ===
 
=== wired interface ===
Line 322: Line 445:
 
'''Note:'''
 
'''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 link to <code>/run/systemd/resolve/stub-resolv.conf</code>
+
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>
  
 
<pre>
 
<pre>
Line 333: Line 456:
 
wpa_supplicant provides different services on systemd:
 
wpa_supplicant provides different services on systemd:
  
* <code>wpa_supplicant.service</code> uses D-Bus, recommende with the ''NetworkManager''
+
* <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 ansd executes the wpa_supplicant daemon on that interface. The configuration file is <code>/etc/wpa_supplicant/wpa_supplicant-interface.conf</code>
+
* <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 start the service
+
For enabling the interface at boot time it is required to ''enable'' the service
  
 
  systemctl enable wpa_supplicant@interface
 
  systemctl enable wpa_supplicant@interface
Line 342: Line 465:
 
==== Configuration example ====
 
==== Configuration example ====
  
Assuming ''wlan0'' as the wireless interface name, the a configuration file example are the following one:
+
Assuming ''wlan0'' as the wireless interface name, the configuration file examples are the following one:
  
 
  /etc/systemd/network/wlan0.network
 
  /etc/systemd/network/wlan0.network
Line 378: Line 501:
 
</pre>
 
</pre>
  
For automatically creating the netwrok configuration, the following command can be used:
+
For automatically creating the network configuration, the following command can be used:
  
 
  wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
 
  wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
  
Then, 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>:
+
Then, the sergice should be enabled on the ''wlan0'' interface for instructing systemd to start it using the (just) created configuration file <code>wpa_supplicant-wlan0.conf</code>:
  
 
  systemctl enable wpa_supplicant@wlan0
 
  systemctl enable wpa_supplicant@wlan0

Revision as of 12:32, 20 September 2019

Info Box
Axel-04.png Applies to Axel Ultra
Axel-02.png Applies to AXEL ESATTA
Axel-lite 02.png Applies to Axel Lite


200px-Emblem-important.svg.png This application note has been validated starting from the XELK 4.0.0 kit version. 200px-Emblem-important.svg.png

History[edit | edit source]

Version Date XELK version Notes
1.0.0 Sep 2019 4.0.0

Introduction[edit | edit source]

Starting from XELK 4.0.0 the root file system generated by NXP Yocto recipes produces a root file system using systemd.

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 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[edit | edit source]

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.

Services[edit | edit source]

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[edit | edit source]

Starting a service from userspace:

systemctl start <service_name>

Stopping a service from userspace

systemctl stop <service_name>

Starting a service at boot time:

systemctl enable <service_name>

Disabling service (already started at boot time):

systemctl disable <service_name>

Targets[edit | edit source]

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

They can be used for set the system to a new state.

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.

Target and runlevels[edit | edit source]

Here below there is a list of power on/off targets and related SystemV runlevels:

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

multi-user target can be identified as the runlevel 3.

On the

/etc/systemd/system/<target_name>.target.wants

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

For example:

root@imx6qxelk:~# ls /etc/systemd/system/multi-user.target.wants/
atd.service	       busybox-syslog.service  gpuconfig.service  ofono.service		systemd-networkd.service
avahi-daemon.service   connman.service	       mytest.service	  psplash-quit.service	systemd-resolved.service
busybox-klogd.service  crond.service	       ntpdate.service	  remote-fs.target

Active targets[edit | edit source]

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[edit | edit source]

For a complete information on Unit please look to the documentation page

Here below you can find an extract for the main used topics and configuration descriptions.

Location Path[edit | edit source]

Units are configured by systemd using configuration files that can be found in different directories. Each of them has different priority and behaviour:

  • /lib/systemd/system

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 /lib/systemd/system. 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[edit | edit source]

This section is used for defining the metadata and relations between different Unit

Please find below the main properties description:

Description=: 

Name and function

Documentation=: 

URI for the documentation

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.

[Install] section options[edit | edit source]

This section is optional but is commonly used for defining a Unit behaviour when it will be executed during enable or disable commands.

WantedBy=:

This is similar to the Wants= on [Unit] section but allows to mantain the top Unit more clean.

When the Unit will be enabled, a directory on /etc/systemd/system will be created with the Unit name adding .wants to the name. Inside this directoty a symbolic link to the Unit is created.

Example:

  • current Unit has WantedBy=multi-user.target
  • a directory /etc/systemd/system/multi-user.target.wants 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 WantedBy= 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.

Specific sections[edit | edit source]

Some Unit have specific sections based on their characteristic. The most important is the section Service related to the Unit .service

Please find more information at the documentation page

[Service] section[edit | edit source]

Used for providing configurations for the services.

Type[edit | edit source]

Type= uses one of the (main) following values:

simple:

Default configuration for a service when specified ExecStarts=

forking:

the process will call a fork() 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 ExecStarts= is not specified.

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[edit | edit source]
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 or stop before considering the process failed on start or stop. Start and stop timeout can be set with different values using TimeoutStartSec= nad e TimeoutStopSec=

Creating a new service[edit | edit source]

For creating a new service the following file has to be created:

/etc/systemd/system/<service_name>.service

Service example[edit | edit source]

The following paragraph shows how to create a new service called myservice executing a command (in our case iperf3):

/etc/systemd/system/myservice.service
[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
Basic settings[edit | edit source]
After 

The executed command (iperf3) requires the network interface to be already active, so we use After 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[edit | edit source]

Starting the service from userspace:

systemctl start myservice

Starting the service at boot time:

systemctl enable myservice

From SystemV to Systemd[edit | edit source]

start[edit | edit source]

Considering a SystemV script executing the start() function as in the following example:

start() {
  echo "Starting My Custom Service..."
  /usr/bin/myservice -D
}

The related command is executed in the custom service /usr/bin/myservice with the same -D parameter. It is possibile to use the ExecStart=:

[Service]
ExecStart=/usr/bin/myservice -D

restart[edit | edit source]

The same SystemV script may use special commands for restarting the service like reboot() function:

reboot() {
  echo "Reloading My Custom Service..."
  /usr/bin/myservice reload
}

which is equivalent to use ExecReload=:

[Service]
ExecReload=/usr/bin/myservice reload

stop[edit | edit source]

The stop() function in the script will become ExecStop=:

SystemV:

stop() {
  echo "Stopping My Custom Service..."
  /usr/bin/myservice shutdown
}

Systemd:

[Service]
ExecStop=/usr/bin/myservice shutdown

Network Configuration[edit | edit source]

One of the most systemd configuration used is the Network configuration.

wired interface[edit | edit source]

systemd uses a slightly different configuration mechanism than SystemV. The configuration file is the following one with an example of configuration:

/etc/systemd/network/eth0.network
[Match]
Name=eth0

# Prevent the interface loading if the kernel boots from nfs
KernelCommandLine=!nfsroot

[Network]
Address=192.168.0.120
Gateway=192.168.0.254
DNS=192.168.0.1
#DNS=8.8.8.8

Note:

The DNS is used only if the systemd-resolved service is enabled and the /etc/resolv.conf has a symbolic link to /run/systemd/resolve/stub-resolv.conf

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

wireless interface[edit | edit source]

wpa_supplicant[edit | edit source]

wpa_supplicant provides different services on systemd:

  • wpa_supplicant.service uses D-Bus, recommended with the NetworkManager
  • wpa_supplicant@interface.service uses the interface name (like wlan0) as parameter and executes the wpa_supplicant daemon on that interface. The configuration file is /etc/wpa_supplicant/wpa_supplicant-interface.conf

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

systemctl enable wpa_supplicant@interface

Configuration example[edit | edit source]

Assuming wlan0 as the wireless interface name, the configuration file examples are the following one:

/etc/systemd/network/wlan0.network
[Match]
Name=wlan0
[Network]
# Uncomment for DHCP
#DHCP=yes
Address=192.168.1.120
Gateway=192.168.1.254
DNS=8.8.8.8

/etc/wpa_supplicant/wpa_supplicant-wlan0.conf
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1

network={
    ssid="SSID1"
    psk="password1"
    priority=1
}
network={
    ssid="SSID2"
    psk="password2"
    priority=2
}

For automatically creating the network configuration, the following command can be used:

wpa_passphrase <ESSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant-wlan0.conf

Then, the sergice should be enabled on the wlan0 interface for instructing systemd to start it using the (just) created configuration file wpa_supplicant-wlan0.conf:

systemctl enable wpa_supplicant@wlan0