Systemd


Systemd arbeitet mit Abhängigkeiten, beim Start werden möglichst viele Prozesse (Units) gleichzeitig gestartet und nur noch ein Start-Skript abgearbeitet. Service Units werden zum verwalten von Diensten verwendet und übernehmen die ähnliche Aufgabe wie die Init Skripte im InitVsystem.

Viele große Linux Systeme nutzen mittlerweile Systemd. Devuan (ein Debian Fork) oder BSD Systeme, wie z.B. FreeBSD 11.1 bevorzugen das InitVsystem.




Im Verzeichnis „/lib/systemd/system/“ befinden sich die Vorinstallierten Units des Systems und in „/etc/systemd/system/“ können Units erstellt oder bearbeitet werden.



Ein Auszug der System Units aus dem „/lib/systemd/system/“ Verzeichnis.

root@home:# ll /lib/systemd/system
....
-rw-r--r-- 1 root root  741 Dez 29  2016 accounts-daemon.service
-rw-r--r-- 1 root root  502 Jan 23  2017 alsa-restore.service
-rw-r--r-- 1 root root  475 Jan 23  2017 alsa-state.service
-rw-r--r-- 1 root root  224 Mai 29 18:36 anacron.service
-rw-r--r-- 1 root root  145 Mai 29 18:36 anacron.timer
-rw-r--r-- 1 root root  169 Jul 13 23:45 apt-daily.service
-rw-r--r-- 1 root root  212 Jul 13 23:45 apt-daily.timer
-rw-r--r-- 1 root root  202 Jul 13 23:45 apt-daily-upgrade.service
-rw-r--r-- 1 root root  184 Jul 13 23:45 apt-daily-upgrade.timer
-rw-r--r-- 1 root root 1044 Jan 23  2017 avahi-daemon.service
-rw-r--r-- 1 root root  874 Jan 23  2017 avahi-daemon.socket
....




Beim bearbeiten der System Units kann es bei einem Update des Systems vorkommen, dass alle editierten Units im Verzeichnis „/lib/systemd/system/“ überschrieben werden.




Nicht überschrieben werden die Units im Verzeichnis „/etc/systemd/system/“.

root@home:# ll /etc/systemd/system
....
drwxr-xr-x 2 root root 4096 Jul  2 14:44 bluetooth.target.wants
lrwxrwxrwx 1 root root   37 Jul  2 14:44 dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root   40 Jul  2 14:47 dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root   40 Jul  2 14:46 dbus-org.freedesktop.ModemManager1.service -> /lib/systemd/system/ModemManager.service
lrwxrwxrwx 1 root root   53 Jul  2 14:46 dbus-org.freedesktop.nm-dispatcher.service -> /lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root   32 Jul 16 01:57 display-manager.service -> /lib/systemd/system/gdm3.service
-rw-r--r-- 1 root root  122 Jul  6 20:17 firewall.service
drwxr-xr-x 2 root root 4096 Jul  2 14:13 getty.target.wants
drwxr-xr-x 2 root root 4096 Jul  2 14:45 graphical.target.wants
drwxr-xr-x 2 root root 4096 Sep  2 22:44 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Jul  2 14:46 network-online.target.wants
drwxr-xr-x 2 root root 4096 Jul  2 14:47 sockets.target.wants
drwxr-xr-x 2 root root 4096 Jul  2 14:15 sysinit.target.wants
lrwxrwxrwx 1 root root   35 Jul  2 14:14 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Jul  2 14:44 timers.target.wants
....




Im Verzeichnis „/etc/systemd/system/“ können Units erstellt und bearbeitet werden. Gleichnamige Units in beiden Verzeichnissen werden von den Units in „/etc/systemd/system/“ überschrieben.






Zur Analyse des Bootvorgangs in systemd gibt es ein in Python entwickelte systemd-analyze Programm. Es sammelt diverse Statuswerte und statistische Informationen des systemd-Frameworks. Zusätzlich kann es alle Unit-Dateien (mit der Konfiguration der Systemobjekte) auf korrekte Syntax überprüfen.


  • systemd-analyze




root@home:~# systemd-analyze time
Startup finished in 5.709s (kernel) + 1min 16.331s (userspace) = 1min 22.040s


Hier weden die Startzeiten von Kernel- und Userspace ausgegeben. Es wird die Zeit, die systemd benötigt, um Sockets einzurichten und den Startvorgang aller Dienste einzuleiten angezeigt.



root@home:~# systemd-analyze blame
         49.569s apt-daily.service
          8.050s vboxdrv.service
          7.903s dev-sda2.device
          6.772s ModemManager.service
          4.964s keyboard-setup.service
          4.862s exim4.service
          ..............


Der Parameter blame gibt eine Liste aller laufenden Units aus, nach der Zeit sortiert, die sie zum Initialisieren benötigt haben.




Mit dem Befehl systemctl Systemd einrichten.


Syntax:

  • systemctl [Opt] [Dienst]




Optionen:

  • start|stop [Dienst] ⇒ Dienste starten oder stoppen.
  • enable|disable [Dienst] ⇒ Dienste aktivieren oder deaktivieren. Es werden SymLinks für den automatischen Start des Units beim Systemstart gesetzt.
  • --all ⇒ Alle Units ausgeben.
  • status [Dienst] ⇒ Status eines Dienstes ausgeben.
  • is-enabled [Dienst] ⇒ Prüft, ob Unit läuft.




Mit „systemctl --all“ können alle laufenden Dienste und Status ausgegeben werden.

root@home:~# systemctl --all
  UNIT                                    LOAD      ACTIVE   SUB       DESCRIPTION  
  ....         
  proc-sys-fs-binfmt_misc.automount       loaded    active   running   Arbitrary Executable F..
  dev-cdrom.device                        loaded    active   plugged   HL-DT-ST_DVDRAM_GH22NS..
  avahi-daemon.service                    loaded    active   running   Avahi mDNS/DNS-SD Stack
  binfmt-support.service                  loaded    active   exited    Enable support 
● clamav-daemon.service                   not-found inactive dead      clamav-daemon.service 
  clamav-freshclam.service                loaded    active   running   ClamAV virus database 
  colord.service                          loaded    active   running   Manage, Install and Ge..
● console-screen.service                  not-found inactive dead      console-screen.service
  console-setup.service                   loaded    active   exited    Set console font
  cron.service                            loaded    active   running   Regular background
  ....




Mehr Informationen zum Status eines Units mit systemctl status [Dienst].

root@home:~# systemctl status cron
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-10-06 09:29:02 CEST; 13h ago
     Docs: man:cron(8)
 Main PID: 648 (cron)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/cron.service
           └─648 /usr/sbin/cron -f

Okt 06 19:17:01 home CRON[16222]: pam_unix(cron:session): session opened for user root
Okt 06 19:17:01 home CRON[16223]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly
Okt 06 20:17:01 home CRON[24812]: pam_unix(cron:session): session opened for user root
Okt 06 20:17:01 home CRON[24813]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly
Okt 06 20:17:01 home CRON[24812]: pam_unix(cron:session): session closed for user root
....
lines 1-19/19 (END)






Mit „service“ werden Dienste gestartet/gestoppt oder neugeladen in dem ein initVscript aufgerufen wird.


Syntax:

  • service [Dienst] [Opt]




Optionen:

  • start|stop|reload|restart ⇒ Dienste starten/stoppen oder neu einlesen.
  • service --status-all ⇒ Listet alle init scripte alphbetisch auf.
  • status ⇒ Status eines Dienstes ausgeben.




Statusausgabe des Units „firewall“.

root@home:~# service firewall status
● firewall.service - Local Firewall
   Loaded: loaded (/etc/systemd/system/firewall.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2017-10-06 17:39:29 CEST; 5h 21min ago
  Process: 1624 ExecStart=/Pfad/zur/local_fw_datei.sh (code=exited, status=0/SUCCESS)
 Main PID: 1624 (code=exited, status=0/SUCCESS)

Okt 06 17:39:29 home systemd[1]: Started Local Firewall.






Eigene Units anlegen oder bearbeiten.


Das Grundgerüst eines Units kann wie folgt aussehen.

[Unit]
Description=Unit Beschreibung
Requires=unit1.service unit2.service
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
ExecStart=/Pfad/zur/Datei




Ein Beispiel des Units „/lib/systemd/system/networking.service“.

root@home:/lib/systemd/system# cat networking.service 
[Unit]
Description=Raise network interfaces
Documentation=man:interfaces(5)
DefaultDependencies=no
Wants=network.target
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service systemd-modules-load.service
Before=network.target shutdown.target network-online.target
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle'
ExecStart=/sbin/ifup -a --read-environment
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
RemainAfterExit=true
TimeoutStartSec=5min




Beschreibung der Sektionen:

[Unit]
Schlüssel Beschreibung
Description Bezeichnung des Units.
Documentation Hinweis zur Manpage.
Requires Hier werden die Units eingetragen, die dieser Unit zum starten unbedingt benötigt.
Wants Es wird zuerst geprüft, ob die eingetragenen Units gestartet werden können.
After Unit wird nach den in After beschriebenen Units gestartet.
Before Unit wird vor den in Before eingetragenen Units gestartet.
Conflicts Unit soll gestartet werden, falls es schwerwiegende Konflikte gibt.



Um mehrere Werte für einen Schlüssel zu verwenden, werden die Parameter mit einem Leerzeichen getrennt eingegeben.




[Install]
Target Beschreibung
multi-user.target Unit startet als Mehrbenutzersystem in der tty und im grafischen Modus. (Standard)
graphical.target Unit startet als Mehrbenutzersystem nur im grafischen Modus.
network-online.target Unit startet nur, wenn eine Netzwerkverbindung besteht.
rescue.target Unit startet nur im Single User System.
reboot.target Dienst wird nur bei einem Neustart ausgeführt.
poweroff.target Dienst wird nur beim Herunterfahren ausgeführt.




[Service]
Schlüssel Beschreibung
Type=oneshot Skript wird nur einmal ausgeführt.
Type=forking Wenn der Dienst weitere Prozesse erzeugt.
ExecStart Hier steht, was beim Start der Unit gestartet werden soll.
ExecStop Was nach dem stoppen des Units gestartet werden soll.
ExecStartPre Was vor dem starten der Unit ausgeführt werden soll.
ExecStartPost Was nach dem starten der Unit ausgeführt werden soll.
WorkingDirectory Legt das Arbeitsverzeichnis fest, in dem die Prozesse ausgeführt werden.
User Unter diesem Nutzer läuft der Dienst. (Standard=root)
Group Unter welcher Gruppe der Dienst laufen soll.



Bei den Exec* Schlüssel muß immer der vollständige Pfad zur Datei eingetragen werden.






Eigene *.service erstellen und aktivieren.


Erstellen einer firewall.service Datei im Verzeichnis „/etc/systemd/system/“, die Berechtigung (Okt: 644) ist hierfür ausreichend und folgendermaßen editieren.

[Unit]
Description=Local Firewall

[Service]
ExecStart=/Pfad/zur/local_firewall.sh

[Install]
WantedBy=multi-user.target




Den Unit mit systemctl aktivieren.

[root@home system]# systemctl enable firewall
Created symlink from /etc/systemd/system/multi-user.target.wants/firewall.service to /etc/systemd/system/firewall.service.




Jetzt sollte der Service neu gestartet werden.

[root@home]# service firewall restart
Redirecting to /bin/systemctl restart firewall.service




Wie folgt, kann der Dienst noch geprüft werden.

[root@home]# service firewall status
Redirecting to /bin/systemctl status firewall.service
● firewall.service - Local Firewall
   Loaded: loaded (/etc/systemd/system/fwall.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mi 2017-10-04 17:52:09 CEST; 4s ago
  Process: 6684 ExecStart=/Pfad/zur/local_fw_datei.sh (code=exited, status=0/SUCCESS)
 Main PID: 6684 (code=exited, status=0/SUCCESS)

Okt 04 17:52:08 home systemd[1]: Started Local Firewall.
Okt 04 17:52:08 home systemd[1]: Starting Local Firewall...



Jetzt wird bei jedem Systemstart das „firewall“ Skript ausgeführt. Zum deaktivieren der Units kann folgendermaßen vorgegangen werden.

[root@home ~]# service firewall stop
Redirecting to /bin/systemctl stop firewall.service



[root@home ~]# systemctl disable firewall.service
Removed symlink /etc/systemd/system/basic.target.wants/firewalld.service.



Wenn Sie Units unter „/lib/systemd/system/“ bearbeiten oder deaktivieren möchten, sollten Sie wissen, was Sie tun.






Möchte man eine Service Unit Datei aus dem Verzeichnis „/lib/systemd/system“ bearbeiten, kann man das mit dem Befehl „systemctl edit --full datei.service“. Hier wird eine Kopie der Datei im Verzeichnis „/etc/systemd/system/“ erstellt und zum bearbeiten mit dem Standard Editor der Shell geöffnet.

Die Units im Systemd Verzeichnis „/etc/systemd/system/“ sind, bei gleicher Unit Datei im „/lib/*“ hierarchisch höhergestellt.



Des weiteren kann mit „systemctl edit datei.service“ eine bestehende Unit Datei überschrieben werden. Es wird die Datei „/etc/systemd/system/datei.service.d/override.conf“ angelegt und mit dem Standard Editor der Shell geöffnet. Nach dem speichern und schließen des Editors wird der Unit neu geladen.

Bei gleichen Schlüssel in der „datei.service“ und „override.conf“, werden die Einstellungen der „override.conf“ bevorzugt.





Cloud

  • Zuletzt geändert: 06.11.2018 22:47
  • von Tom