Diskussion:Systemd: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
VisuellWikitext
Die Seite wurde neu angelegt: „= TMP 3 = == systemd == {| class="wikitable sortable" |- || ||Inc.) |- ||'''Erscheinungsjahr''' ||März 2010 |- ||'''Aktuelle''' ||224 (31. * Juli 2015) |- || || |- || || |- || '''Kategorie''' || -Dienst |- ||'''Lizenz''' ||) |- | colspan="2" |[http://freedesktop.org/wiki/Software/systemd freedesktop.org/wiki/Software/systemd] |- |} *'''systemd''' ist ein Hintergrundprogramm ([https://de.wikipedia.org/wiki/Daemon Daemon]) für 1) zum Starten, Überwachen…“
 
Keine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
= TMP 3 =
= TMP =
== systemd ==
{{DISPLAYTITLE:systemd}}
{| class="wikitable sortable"
|-
||
||Inc.)
|-
||'''Erscheinungsjahr'''
||März 2010
|-
||'''Aktuelle'''
||224 (31.
* Juli 2015)
|-
||
||
|-
||
||
|-
|| '''Kategorie'''
|| -Dienst
|-
||'''Lizenz'''
||)
|-
| colspan="2" |[http://freedesktop.org/wiki/Software/systemd freedesktop.org/wiki/Software/systemd]
|-
|}


*'''systemd''' ist ein Hintergrundprogramm ([https://de.wikipedia.org/wiki/Daemon Daemon]) für 1) zum Starten, Überwachen und Beenden weiterer Prozesse dient.
== Anpassen von systemd ==
*Es wurde von (LGPL) veröffentlicht.
; Warnung
*Der Name entspricht mit dem abschließenden „d“ dem für Daemons üblichen Namensschema: systemd ist der Daemon, der das System startet und betreut.
: Vermeiden der Überschreibung von Anpassungen
: Passen Sie systemd stets in <tt>/etc/systemd/</tt> an, ''nicht'' in <tt>/usr/lib/systemd/</tt>.
:* Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd überschrieben.


=====Geschichte=====
===Anpassen von Unit-Dateien===
======Ideen und Konzepte======
Die systemd-Unit-Dateien befinden sich in<tt>/usr/lib/systemd/system</tt>.
*Die Ideen und Konzepte zu systemd entstanden aus der Betrachtung von bereits bestehenden modernisierten init-Systemen wie.
* Zum Anpassen fahren Sie wie folgt fort: # Kopieren Sie die zu bearbeitenden Dateien aus <tt>/usr/lib/systemd/system</tt> in <tt>/etc/systemd/system</tt>.
* Es wurde am  April 2010 veröffentlicht.
* Behalten Sie die ursprünglichen Dateinamen bei.
#Bearbeiten Sie die Kopien in <tt>/etc/systemd/system</tt>.
#Mit dem Kommando <tt>systemd-delta</tt> erhalten Sie einen Überblick über Ihre Konfigurationsänderungen.
* Hiermit werden Konfigurationsdateien verglichen und ermittelt, die andere Konfigurationsdateien überschreiben.
* Weitere Informationen finden Sie auf der man-Seite zu <tt>systemd-delta</tt>.


======Distributionen======
Die geänderten Dateien in <tt>/etc/systemd</tt> haben Vorrang vor den Originaldateien in <tt>/usr/lib/systemd/system</tt>, sofern die Dateinamen identisch sind.
Distributionen, die systemd als vorgegebenen init-Dienst verwenden, sind ab Version 8.


Ab Version 221 beinhaltet systemd ''sd-bus'', eine unabhängige als Backend und soll so den reibungslosen Übergang zur Interprozesskommunikation im Kernel ermöglichen.
====Konvertieren von xinetd-Diensten in systemd====
Seit der Version SUSE Linux Enterprise Desktop 15 wurde die <tt>xinetd</tt>-Infrastruktur entfernt.
* In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte <tt>xinetd</tt>-Dienstdateien in <tt>systemd</tt>-Sockets konvertieren.


=====Technik =====
Für jede <tt>xinetd</tt>-Dienstdatei benötigen Sie mindestens zwei <tt>systemd</tt>-Unit-Dateien: die Socket-Datei (<tt> *.socket </tt>) und eine zugehörige Dienstdatei (<tt>*.service</tt>).
*systemd ist abwärtskompatibel zu.
* Die Socket-Datei weist <tt>systemd</tt> an, welcher Socket erstellt werden soll, und die Dienstdatei weist <tt>systemd</tt> an, welche ausführbare Datei gestartet werden soll.
* Es kann daher nur auf Systemen mit Linux-Kernel laufen.
*[[Image:.png|thumb|right|Abbildung 1: systemd-Komponenten]]Es soll den gegenseitigen Abhängigkeiten von Prozessen besser gerecht werden, durch mehr Parallelisierung zu einer besseren Auslastung beim Systemstart führen und somit weniger Verzögerungen verursachen als das ältere, klassische SysVinit oder das inzwischen auch von Ubuntu aufgegebene.
*Grundlegendes Konzept dafür ist es, weitgehend alle Prozesse gleichzeitig zu starten.
*Um nicht, wie bei anderen zwar grundsätzlich auf Parallelisierung setzenden Systemen, anhand der in einem Modell erfassten wechselseitigen Abhängigkeiten der Prozesse teilweise noch mit Serialisierung zu arbeiten, werden die.
*Ähnliches wird für Anfragen an Dateisysteme mittels bewerkstelligt.
*Daneben kann es nur gelegentlich benötigte Dienste ereignisbasiert erst bei Bedarf starten und so beim Systemstart weniger Dienste starten.
* Damit nimmt es Aufgaben wahr, die bei klassischen Unix-Systemen von übernommen werden.
*Weiterhin sollen alle Shell-Boot-Skripte durch deklarative Konfigurationsdateien ersetzt werden, in denen definiert wird, wie die jeweiligen Dienste gestartet werden.
* Diese Dateien sind in der Regel deutlich einfacher zu schreiben als init-Skripte und vermeiden den erheblichen Overhead von Shell-Skripten.


=====Kritik =====
Betrachten Sie das folgende Beispiel für eine <tt>xinetd</tt>-Dienstdatei:
*Der Hauptkritikpunkt am systemd liegt in seinem Anspruch, deutlich mehr verschiedene Aufgaben als das alte SysV-Init erledigen zu wollen, was ihn recht kompliziert und fehleranfällig mache und überdies die verletze, dass ein Programm ein Problem gut lösen sollte, anstatt viele Aufgaben schlecht zu lösen.
# '''cat /etc/xinetd.d/example'''
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}


===Aufgaben===
Zum Konvertieren in <tt>systemd</tt> benötigen Sie die folgenden beiden Dateien:
*Der Init-Prozess ist der erste Prozess, den der Kernel erzeugt.
* Alle weiteren Prozesse sind Kinder des Init-Prozesses, der daher die Verantwortung für die komplette Einrichtung des Userlands trägt.
*Dazu gehört nicht nur das Einhängen von Dateisystemen und die Netzwerkeinrichtung, sondern auch das Starten von Hintergrund-Diensten und Programmen – darunter auch jene, über die sich Benutzer am System anmelden.
*Nach dem Abschluss der Systemeinrichtung läuft der Init-Prozess weitgehend untätig im Hintergrund weiter.
* Er kommuniziert mit dem Kernel und wird beispielsweise informiert, wenn der Benutzer Strg+Alt+Entf drückt.
*Genau wie beim Aufruf von Befehlen wie <tt>shutdown -r now </tt>oder <tt>reboot</tt> erledigt der Prozess mit der PID 1 dann alles Nötige, um das System sauber zum Stillstand zu bringen.
*Mit diesen Aufgaben wurde in den 80er Jahren in Unix System V das einfache, aber flexible "System V Init System" betraut.
* In den 90er Jahren entstand eine Sysvinit genannte Neuimplementierung dieses Init-Systems.
*Sie arbeitet mit einer ganz ähnlichen Logik und kommt bis heute bei vielen Linux-Distributionen zum Einsatz.
* Sysvinit erledigt die Aufgaben des Systemstarts im Wesentlichen mit Shell-Skripten, die einfach der Reihe nach abgearbeitet werden.
*Mit der Verbreitung von Linux in Mobilgeräten, Desktop-PCs, Fernsehern und zahlreichen anderen Gebieten wandelten sich allerdings die Anforderungen an den Init-Prozess: Der Systemstart sollte flexibler werden und dank Parallelisierung deutlich schneller ablaufen.


===Herangehensweisen===
# '''cat /usr/lib/systemd/system/example.socket'''
*Lange schien es, als wäre '''das 2006 '''von einem Canonical-Entwickler gestartete Upstart der designierte Nachfolger für Sysvinit (siehe den Artikel '''Schneller booten mit Upstart '''auf heise open).
[Socket]
*Anfangs kam es nur bei Ubuntu zum Einsatz, später auch bei Fedora (Versionen 9 bis 14) und Red Hat Enterprise Linux (RHEL6-Familie).
  ListenStream=0.0.0.0:10085
* OpenSuse experimentierte während der Arbeit an der Version mit Upstart, blieb letztlich jedoch bei Sysvinit.
Accept=false
*Upstart ist ein ereignisorientiertes Init-System – es kann Dienste starten, wenn Ereignisse wie "Netzwerk ist konfiguriert" oder "Netzlaufwerk ist eingebunden" eintreten.
* Der Ansatz unterscheidet sich stark von dem statischen Sysvinit, daher lassen sich bestehende Konfigurationen nur schwer oder gar nicht in das Ereignis-Modell von Upstart übertragen.
*Im '''April 2010 '''erschien Systemd; es bedient sich einiger Ideen aus früheren Unit-Systemen und kombiniert diese mit einer einheitlichen Konfigurations- und Administrationsschnittstelle.
* Systemd arbeitet als Hintergrunddienst (Daemon) und steuert wichtige Aspekte der Systemkonfiguration von der Initialisierung der Hardware bis zu den gestarteten Server-Prozessen.
*Der Name erschien den Entwicklern als eine '''passende Verbindung '''zum französischen Begriff "Système D" (etwa: "Trick 17"), der kreative technische Lösungsansätze à la '''MacGyver '''beschreibt.


===Hintenrum===
[Install]
*Zentrales Merkmal von Systemd ist die Socket-Aktivierung, durch die der Daemon Hintergrunddienste ohne explizite Konfiguration der Abhängigkeiten parallel starten kann, sobald die Grundeinrichtung des Systems abgeschlossen und die lokalen Dateisysteme eingebunden sind.
WantedBy=sockets.target
*Der Trick besteht darin, dass Systemd die Sockets zur Kommunikation mit den zu startenden Diensten selbst anlegt und dorthin geschriebene Daten zwischenspeichert, bis sie der gestartete Dienst entgegennehmen kann.
root # cat /usr/lib/systemd/system/example.service
*Illustrieren lässt sich das Konzept am Beispiel der Dienste Syslog und D-Bus.
[Unit]
* Letzterer verbindet sich beim Start mit dem Socket /dev/log, um darüber bei Bedarf Status- und Fehlermeldungen über den Log-Daemon ins Systemlog zu schreiben.
  Description=example
* Sysvinit kann daher D-Bus erst starten, wenn der Syslog-Dienst voll einsatzbereit ist.
*Systemd hingegen legt /dev/log selbst an und startet Syslog und D-Bus gleichzeitig; dabei werden die Daten, die D-Bus an /dev/log schickt, gepuffert, bis sie Syslog entgegennimmt.
* Anfangs überließ Systemd dem Kernel das Puffern; bei aktuellen Versionen vom Systemd kümmert sich die '''dort enthaltene '''Log-Funktion "Journal" um diese Aufgabe.
*Systemd kann so auch Bluetooth, Avahi und weitere Dienste, die mit dem Log-Daemon oder D-Bus kommunizieren, parallel mit Syslog und D-Bus starten.
*Wenn Avahi beim Start eine Antwort von D-Bus erwartet, stoppt der Prozess an dieser Stelle automatisch und setzt den Start ohne weiteres Zutun fort, sobald die Antwort über den Socket eintrifft.
* Sollte D-Bus aus irgendeinem Grund nicht anlaufen, bricht Systemd den Start von Bluetooth und Avahi nach einiger Zeit ab.
*Apple verwendet dasselbe Prinzip in seinem mit Mac OS X eingeführten '''Launchd ''', der auch bei iOS zum Einsatz kommt und als Hauptgrund für den deutlich verkürzten Startprozess neuerer Mac-OS-Versionen gilt, da der Parallelstart der Dienste die verfügbaren CPU- und I/O-Ressourcen effizienter nutzt.
*Bei Sysvinit starten die Dienste hingegen in einer festgelegten Reihenfolge – Bluetooth und Avahi erst, wenn der D-Bus-Daemon läuft, der wieder erst startet, wenn das Syslog bereit ist.
* Selbst Bluetooth und Avahi, die voneinander unabhängig sind, starten nicht bei allen Sysvinit-Distributionen parallel.


===Bedarfsanforderung===
[Service]
*Da Systemd den Socket erstellt und hält, kann der Daemon einen abgestürzten Dienst neu starten, ohne dass mit dem Socket verbundene Programme die Verbindung verlieren.
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
* Dadurch lassen sich System-Komponenten einfacher aktualisieren, da der Kernel die über den Socket eingehenden Client-Anfragen während des Neustarts puffert und der neue Dienst einfach dort fortfahren kann, wo der alte aufgehört hat.
User=user
*Sockets lassen sich zudem an verschiedene Programme übergeben.
Group=users
* Systemd nutzt das zum Loggen von früher Statusmeldungen:
StandardInput=socket
*Solange das Root-Dateisystem noch nicht beschreibbar eingebunden ist, nimmt ein minimaler Log-Dienst Daten entgegen, die nach /dev/log geschrieben werden, und schreibt sie in den Kernel-Log-Puffer.
* Sobald der eigentliche Syslog-Server bereits ist, wird der Minidienst beendet; der Syslog-Daemon übernimmt den Socket und schreibt dabei alle zuvor aufgelaufenen Nachrichten aus dem Kernel-Log-Buffer auf die Festplatte.
*So gehen keine Nachrichten verloren, was eine Protokollierung vom ersten Moment des Bootens an ermöglicht.


===Einheiten===
Eine vollständige Liste der Socket- und Dienstdateioptionen für <tt>systemd</tt> finden Sie auf den man-Seiten zu systemd.socket und systemd.service (<tt>man 5 systemd.socket</tt>, <tt>man 5 systemd.service</tt>).
*Die verschiedenen Tätigkeiten beim Systemstart – Sockets anlegen, Hardware einrichten, Datenträger einbinden, Hintergrunddienste starten und so weiter – sind in sogenannten Units organisiert.
*Für jede Aufgabe, die Systemd ausführen soll, benötigt man eine Unit-spezifische Konfigurationsdatei – bei einer Mount-Unit beispielsweise muss die Konfiguration lediglich die Device-Datei des Datenträgers und das Zielverzeichnis enthalten.
* Diese Unit-Dateien sind erheblich kürzer als traditionelle Init-Skripte.
* Syntaktisch ähneln sie den Ini-Dateien von Windows.


Den Typ einer Unit erkennt Systemd am Dateinamen.
===Erstellen von „Drop-in-Dateien“===
* Dateien, die auf <tt>.service</tt> enden, legen Service-Units an; sie kümmern sich um Hintergrunddienste.
Wenn eine Konfigurationsdatei nur um wenige Zeilen ergänzt oder nur ein kleiner Teil daraus geändert werden soll, können Sie sogenannte „Drop-in-Dateien“ verwenden.
* Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.


Units zum Ein- und Aushängen von Dateisystemen enden auf <tt>.mount</tt>; das Suffix lautet <tt>.automount</tt>, wenn dabei der Automounter involviert ist, der Dateisysteme beim Zugriff automatisch einhängt.
Um beispielsweise einen einzigen Wert für den Dienst ''foobar'' in <tt>/usr/lib/systemd/system/ ''foobar.service''</tt> zu ändern, gehen Sie wie folgt vor: # Erstellen Sie ein Verzeichnis mit dem Namen <tt>/etc/systemd/system/''FOOBAR''.service.d/</tt>.
* Units mit dem Suffix <tt>.path</tt> weisen Systemd an, die spezifizierten Dateien und Verzeichnisse via Inotify überwachen; erfolgt dort ein Zugriff, startet Systemd diese Unit.


Auf <tt>.socket</tt> endende Unit-Dateien legen einen oder mehrere Sockets für die Socket-Aktivierung an.
Beachten Sie das Suffix <tt>.d</tt>.
* Der zugehörige Dienst wird erst dann über eine zu der Socket-Unit gehörende Service-Unit gestartet, wenn ein anderer Prozess Daten auf den Socket schreibt.
* Ansonsten muss der Name des Verzeichnisses mit dem Namen des Dienstes übereinstimmen, der mit der Drop-in-Datei gepatcht werden soll.
#Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen <tt>''whatevermodification''.conf</tt>.


Der geöffnete Socket wird dabei an den Dienst übergeben – ähnlich wie es alte Unix-/Linux-Hasen von Inetd kennen.
Diese Datei darf nur eine Zeile mit dem zu ändernden Wert enthalten.
# Speichern Sie Ihre Änderungen in die Datei.
* Die Datei wird als Erweiterung der Originaldatei verwendet.


Die Unit-Dateien von Systemd und den Systemdiensten liegen im Verzeichnis /lib/systemd/system/; liegt eine gleichnamige Datei in /etc/systemd/system/, ignoriert Systemd die im Lib-Verzeichnis.
===Erstellen von benutzerdefinierten Zielen===
Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können.
* Mit systemd können Sie beliebig viele benutzerdefinierte Ziele erstellen.
* Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise <tt>graphical.target</tt>. # Kopieren Sie die Konfigurationsdatei <tt>/usr/lib/systemd/system/graphical.target</tt> in <tt>/etc/systemd/system/''MEIN_ZIEL''.target</tt> und passen Sie sie nach Bedarf an.
# Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen („harten“) Abhängigkeiten für das Ziel.
* Um auch die erwünschten („weichen“) Abhängigkeiten abzudecken, erstellen Sie ein Verzeichnis mit dem Namen <tt>/etc/systemd/system/''MEIN_ZIEL''.target.wants</tt>.
#Legen Sie für jeden erwünschten Dienst einen symbolischen Link von <tt>/usr/lib/systemd/system</tt> in <tt>/etc/systemd/system/''MEIN_ZIEL''.target.wants</tt> an.
#Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die systemd-Konfiguration neu.
* Damit wird das neue Ziel verfügbar:


Der Administrator kann so eine Unit-Datei von Systemd kopieren und an seine Belange anpassen, ohne fürchten zu müssen, dass sie beim nächsten Update überschrieben wird – das konnte bei Sysvinit-Distributionen passieren, wenn man eines der in /etc/rc.d/init.d/ gespeicherten Init-Skripte von Hand veränderte.
# '''systemctl daemon-reload'''


Systemd erzeugt einige Units dynamisch selbst; sie tauchen daher nicht im Dateisystem, sondern nur in der mit <tt>systemctl</tt> abrufbaren Liste der Units auf.
== Erweiterte Nutzung ==
In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren.
* Eine noch eingehendere Dokumentation finden Sie in der Serie von Lennart Pöttering zu systemd für Administratoren unter http://0pointer.de/blog/projects.


So wird für einige Geräte wie Datenträger, PCI-Geräte und TTYs im Zusammenspiel mit Udev automatisch eine Device-Unit generiert, wenn sie in den Udev-Regeln mit <tt>TAG+="systemd"</tt> gekennzeichnet sind.
===Bereinigen von temporären Verzeichnissen===
<tt>systemd</tt> unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse.
* Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. <tt>tmpfiles.d</tt> (verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien <tt>/etc/tmpfiles.d/*.conf</tt>, <tt>/run/tmpfiles.d/*.conf</tt> und <tt>/usr/lib/tmpfiles.d/*.conf</tt> aus.
* Die Konfiguration in <tt>/etc/tmpfiles.d/*.conf</tt> hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In <tt>/usr/lib/tmpfiles.d/*.conf</tt> speichern die Pakete die Konfigurationsdateien.)


Ähnlich wie beim Zweigespann aus Socket- und Service-Unit können andere Units von diesen Device-Units abhängen und so automatisch starten, wenn Geräte auftauchen, auf die sie angewiesen sind.
Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann.
* Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben:


Dieses System kommt auch bei den .swap-Units zum Einsatz, die automatisch mit Hilfe der Angaben in /etc/fstab angelegt werden und die den Auslagerungsspeicher einbinden, sobald das spezifizierte Swap-Volume auftaucht.
Type Path              Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock


Systemd erzeugt auch für einige andere in /etc/fstab spezifizierte Datenträger automatisch Mount-Units, daher tauchen in der Systemctl-Liste mehr Mount-Units auf, als man Konfigurationsdateien findet.
So rufen Sie den Status aus dem tmpfile-Zeitgeber ab:


===Ziele===
# '''systemctl status systemd-tmpfiles-clean.timer'''
Unit-Dateien, die auf <tt>.target</tt> enden, definieren Gruppen aus Units.
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
* Sie leisten selbst wenig, rufen vielmehr andere Units auf, die für Dienste, Dateisysteme und andere Dinge zuständig sind.
  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
  Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
  Docs: man:tmpfiles.d(5)
        man:systemd-tmpfiles(8)


So lassen sich Boot-Ziele definieren, die den klassischen Sys-V-Runlevels entsprechen.
Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
* Die Unit <tt>multi-user.target</tt> etwa sorgt für den Start all jener Dienste, die ältere Fedora- und OpenSuse-Versionen im Runlevel 3 aufrufen würden – voller Multiuser-Netzwerkbetrieb ohne grafischen Anmeldemanager.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.


Letzterer erscheint bei der Unit <tt>graphical.target</tt>, die damit das Äquivalent zum Runlevel 5 darstellt und typischerweise das Standard-Ziel ist.
Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter <tt>man 5 tmpfiles.d</tt>.


Beim Hochfahren des Systems aktiviert Systemd die spezielle Target-Unit <tt>default.target</tt>, typischerweise ein Alias eines anderen Targets wie <tt>graphical.target</tt> oder <tt>multi-user.target</tt>.
===Systemprotokoll===
In wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen.
* Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt.
* Sie können auch auf das gesamte von <tt>systemd</tt> geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen.
* Mit dem Befehl <tt>journalctl</tt> zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen.
* Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter <tt>man 1 journalctl</tt>.


Die Targets können zudem aufeinander aufbauen oder voneinander abhängen; <tt>graphical.target </tt>etwa wartet den Start von <tt>multi-user.target</tt> ab, bevor es die grafische Oberfläche startet.
===Aufnahmen ===
Mit dem Subkommando <tt>isolate</tt> können Sie den aktuellen Status von <tt>systemd</tt> als benannten Snapshot speichern und später wiederherstellen.
* Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können.
* Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht.
* Der Snapshot-Name muss auf <tt>.snapshot</tt> enden.


Wo nötig lassen sich über die Angabe von "Wants" in den Unit-Dateien manuell Abhängigkeiten zwischen den Units definieren – wichtig beispielsweise für Dienste wie den Apache-Webserver, der beim Start eine voll konfigurierte Netzwerkumgebung erwartet.
Erstellen eines Snapshots


Solche Dienste sollten von <tt>network.target</tt> abhängen.
# '''systemctl snapshot ''MY_SNAPSHOT''.snapshot'''
* Bei Diensten wie Avahi oder Bind ist eine solche Abhängigkeit nicht nötig, da diese auch mit Netzwerk-Interfaces zurechtkommen, die zur Laufzeit erscheinen oder verschwinden.


===Althergebrachtes===
Löschen eines Snapshots
Aus Kompatibilitätsgründen versteht sich Systemd auch mit System-V- und LSB-Init-Skripten, die nicht nur von Sysvinit-Distributionen verwendet werden, sondern auch mit Upstart funktionieren.


Diese Init-Skripte werden durch eine Shell interpretiert und erfordern einen Parameter wie "start", "stop" oder "restart".
# '''systemctl delete ''MY_SNAPSHOT''.snapshot'''


Auch die Hersteller kommerzieller Software legen ihren Hintergrunddiensten typischerweise Sys-V- und LSB-Init-Skripte bei.
Anzeigen eines Snapshots
* Um sie intern wie eine richtige Service-Unit zu behandeln, generiert Systemd daraus automatisch eine Service-Unit; das Init-Tool ignoriert allerdings Sys-V- und LSB-Init-Skripte, wenn es eine Unit-Datei mit gleichem Namen findet.


=== Gruppen ===
  # '''systemctl show ''MY_SNAPSHOT''.snapshot'''
Systemd packt jeden Dienst beim Start in eine eigene, nach dem Dienst benannte '''Control Group'''.
* Diese Technik isoliert die Prozesse und bietet mit Hilfe '''optionaler Controller '''Stellschrauben, um die Verteilung der Ressourcen zu beeinflussen.
* Kindprozesse erben die Gruppenzugehörigkeit.


Systemd kann so Prozessgruppen als zusammengehörige Einheiten verwalten, um etwa beim Beenden eines Dienstes alle zugehörigen Prozesse zuverlässig zu stoppen.
Aktivieren eines Snapshots
* Administratoren können über die normalen Cgroup-Schnittstellen den Ressourcenverbrauch von Diensten kontrollieren; die manuelle Zuordnung der Prozesse entfällt.


===Breiterer Ansatz===
# '''systemctl isolate ''MY_SNAPSHOT''.snapshot'''
Systemd liegen eine Reihe von Units bei, die einige grundsätzliche Dinge bei der Initialisierung des Systems erledigen.
* Teilweise sind diese wie ein Hintergrunddienst angelegt.


Die Service-Unit <tt>fsck-root.service</tt> etwa veranlasst bei Bedarf eine Prüfung des Root-Dateisystems, bevor es durch <tt>remount-rootfs.service</tt> beschreibbar eingebunden wird.
===Laden der Kernelmodule===
Mit <tt>systemd</tt> können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in <tt>/etc/modules-load.d</tt>.
* Die Datei sollte den Namen ''MODUL''.conf haben und den folgenden Inhalt aufweisen:


Die Service-Units <tt>hwclock-load</tt> und <tt>hwclock-save</tt> sorgen für einen Abgleich der Zeit mit der Systemuhr.
# load module  ''MODULE'' at boot time
''MODULE''


Bei Sysvinit- und Upstart-Distributionen kümmern sich Shell-Skripte um derartige Aufgaben, etwa /etc/rc.sysinit oder eine Sammlung kleiner Skripte in /etc/rcS.d/.
Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter <tt>/usr/lib/modules-load.d</tt> installiert.
* Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter <tt>/etc/modules-load.d</tt> Vorrang.


Diese Skripte sind stark auf die jeweilige Distributionsfamilie zugeschnitten und verhalten sich daher bei Debian ganz anders als bei Fedora oder OpenSuse; das ist der Grund, warum man bei Fedora und RHEL in /etc/sysconfig/keyboard die Tastatur festlegen kann, dieses Verzeichnis bei Debian aber vergeblich sucht.
Weitere Informationen finden Sie auf der man-Seite <tt>modules-load.d(5)</tt>.


Viele Systemd-Units starten C-Programme, die schneller und robuster sein sollen als die Shell-Skipte, die diese Aufgaben bisher erledigten.
===Ausführen von Aktionen vor dem Laden eines Dienstes===
Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in <tt>/etc/init.d/before.local</tt> festgelegt werden.
* Dieses Verfahren wird in systemd nicht mehr unterstützt.
* Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:


Mit der Integration dieser Dienste versucht Systemd viele Unterschiede zwischen den Distributionen aus der Welt zu schaffen.
Laden der Kernelmodule


Das erleichtert Entwicklern die Arbeit, denn sie können Unit-Dateien für ihre Dienste mitliefern und dabei die Dinge erwarten, die Systemd beiliegen.
Erstellen Sie eine Drop-in-Datei im Verzeichnis <tt>/etc/modules-load.d</tt> (Syntax siehe <tt>man modules-load.d</tt>).


Sys-V-Init-Skripte beizulegen ist erheblich schwieriger, weil diese auf distributionsspezifische Eigenarten Rücksicht nehmen müssen.
Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers


===Details ===
Erstellen Sie eine Drop-in-Datei in <tt>/etc/tmpfiles.d</tt> (Syntax siehe <tt>man tmpfiles.d</tt>).
Weitere Hintergründe zu Ideen, Arbeitsweisen und Einsatz von Systemd liefern die '''Man-Pages zu Systemd '''– etwa '''systemd '''und '''systemd.conf '''.


Auch für jeden der Unit-Typen gibt es Man-Pages – beispielsweise '''systemd.unit '''oder '''systemd.service '''. Über die '''Homepage von Lennart Poettering '''findet man '''zahlreiche Artikel ''', die Hintergründe zum Init-System erläutern, darunter die bislang zwei Teile umfassende Serie "systemd for Developers":* Part I: Socket Activation
Weitere Aufgaben
* Part II: Socket Activation (Part II)


Im '''dritten "Systemd Status Update" '''hat Poettering zudem vor Kurzem einige der Neuerungen aufgelistet, die in den letzten eineinhalb Jahren in Systemd eingeflossen sind.
Erstellen Sie eine Systemdienstdatei (beispielsweise <tt>/etc/systemd/system/before.service</tt>) anhand der folgenden Schablone:


Im '''zweiten Teil des Artikels '''geht es um Systemd aus Adminsicht: Aufbau von Unit-Dateien, Befehle zum Auflisten, Starten und Stoppen von Units, Statusausgaben und Beheben von Problemen.
[Unit]
Before=''NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE''
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=''YOUR_COMMAND''
  # beware, executable is run directly, not through a shell, check the man pages
  # systemd.service and systemd.unit for full syntax
[Install]
  # target in which to start the service
WantedBy=multi-user.target
  #WantedBy=graphical.target


/lib/systemd/systemd-sysv-install
Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als <tt>root</tt>):


=== Weitere Informationen ===
# '''systemctl daemon-reload'''
#Startseite: http://www.freedesktop.org/wiki/Software/systemd
# '''systemctl enable before'''
#systemd für Administratoren: Lennart Pöttering, einer der systemd-Autoren, hat eine Serie von Blogeinträgen verfasst. (Zum Zeitpunkt, als dieses Kapitel verfasst wurde, standen bereits 13 Einträge zur Verfügung.) Diese sind unter http://0pointer.de/blog/projects zu finden.
 
Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen:
 
# '''systemctl daemon-reload'''
 
===Kernel-Steuergruppen (cgroups)===
Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde.
* Einige Dienste (z.&nbsp;B.&nbsp; Apache) erzeugen zahlreiche externe Prozesse (z.&nbsp;B.&nbsp; CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen.
* Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich.
* Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf.
* einige untergeordnete Dienste weiterhin aktiv.
 
Bei systemd wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist.
* cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden.
* Die cgroups werden dabei nach dem jeweiligen Dienst benannt.
* Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.
 
Mit dem Kommando <tt>systemd-cgls</tt> erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:
 
======Auflisten aller Prozesse, die zu einem Dienst gehören======
root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│  ├─session-102.scope
│  │ ├─12426 gdm-session-worker [pam/gdm-password]
│  │ ├─15831 gdm-session-worker [pam/gdm-password]
│  │ ├─15839 gdm-session-worker [pam/gdm-password]
│  │ ├─15858 /usr/lib/gnome-terminal-server
[...]
└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D
 
[...]
 
Weitere Informationen zu cpgroups finden Sie in [Fixme]
 
===Beenden von Diensten (Senden von Signalen) ===
Wie in erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden.
* Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste.
* Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.
 
Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, so dass Sie ein Signal zu diesen Prozessen senden können.
* Mit Use <tt>systemctl kill</tt> senden Sie die Signale an die Dienste.
* Eine Liste der verfügbaren Signale finden Sie in <tt>man 7 signals</tt>.
 
Senden von <tt>SIGTERM</tt> an einen Dienst
 
<tt>SIGTERM</tt> ist das standardmäßig gesendete Signal.
 
# '''systemctl kill ''MY_SERVICE'''''
 
Senden von ''SIGNAL'' an einen Dienst
 
Mit der Option <tt>-s</tt> legen Sie das zu sendende Signal fest.
 
# '''systemctl kill -s ''SIGNAL'' ''MY_SERVICE'''''
 
'''Auswählen von Prozessen'''
 
Standardmäßig sendet das Kommando <tt>kill</tt> das Signal an <tt>alle</tt> Prozesse der angegebenen cgroup.
* Sie können dies jedoch auf den Prozess <tt>control</tt> oder <tt>main</tt> beschränken.
* Damit können Sie beispielsweise das Neuladen der Konfiguration eines Dienstes mit dem Signal <tt>SIGHUP</tt> erzwingen:
 
# '''systemctl kill -s SIGHUP --kill-who=main ''MY_SERVICE'''''
 
Warnung: Beenden oder Neustarten des D-BUS-Dienstes wird nicht unterstützt
Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. <tt>dbus</tt> ist zwar ein eigenständiger Daemon, bildet jedoch auch einen wesentlichen Bestandteil der Initialisierungsinfrastruktur.
 
Das Beenden von <tt>dbus</tt> oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten.
* Hiermit wird die systemd-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd-Funktionen unbrauchbar werden.
 
Das Beenden oder Neustarten von <tt>dbus</tt> wird daher weder empfohlen noch unterstützt.
 
===Fehlersuche für Dienste===
Standardmäßig ist die Ausgabe von systemd auf ein Minimum beschränkt.
* Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe.
* Bei einem Fehler wird eine kurze Fehlermeldung angezeigt.
* Mit <tt>systemctl status</tt> können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.
 
systemd umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden.
* Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen.
* Das Kommando <tt>status</tt> hat eine ähnliche Funktion wie <tt>tail</tt> und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.
 
Anzeigen von Fehlern beim Starten von Diensten
 
Wenn ein Dienst nicht gestartet wird, erhalten Sie mit <tt>systemctl status ''MEIN_DIENST''</tt> eine ausführliche Fehlermeldung:
 
# '''systemctl start apache2'''
Job failed.
* See system journal and 'systemctl status' for details.
root # systemctl status apache2
  Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
  Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago
  Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
  CGroup: name=systemd:/system/apache2.service
 
Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>
 
Anzeigen der letzten ''n'' Dienstmeldungen
 
Standardmäßig zeigt das Subkommando <tt>status</tt> die letzten zehn Meldungen an, die ein Dienst ausgegeben hat.
* Mit dem Parameter <tt>--lines=''n''</tt> legen Sie eine andere Anzahl fest:
 
# '''systemctl status chronyd'''
# '''systemctl --lines=20 status chronyd'''
 
Anzeigen von Dienstmeldungen im Anhängemodus
 
Mit der Option „--follow“ erhalten Sie einen <tt>Live-Stream</tt> mit Dienstmeldungen; diese Option entspricht <tt>tail -f</tt>:
# '''systemctl --follow status chronyd'''
 
Ausgabeformat der Meldungen
 
Mit dem Parameter <tt>--output=''mode''</tt> legen Sie das Ausgabeformat für die Dienstmeldungen fest.
* Die wichtigsten Modi sind:
 
<tt>short</tt>
 
Das Standardformat.
* Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.
 
<tt>verbose</tt>
 
Vollständige Ausgabe mit sämtlichen Feldern.
 
<tt>cat</tt>
 
Kurze Ausgabe ohne Zeitstempel.


[[Kategorie:Linux/Dienst]]
[[Kategorie:Systemd]]
[[Kategorie:Systemd]]




{{DEFAULTSORT:systemd}}
{{DEFAULTSORT:systemd}}

Aktuelle Version vom 23. Oktober 2024, 11:45 Uhr

TMP

Anpassen von systemd

Warnung
Vermeiden der Überschreibung von Anpassungen
Passen Sie systemd stets in /etc/systemd/ an, nicht in /usr/lib/systemd/.
  • Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd überschrieben.

Anpassen von Unit-Dateien

Die systemd-Unit-Dateien befinden sich in/usr/lib/systemd/system.

  • Zum Anpassen fahren Sie wie folgt fort: # Kopieren Sie die zu bearbeitenden Dateien aus /usr/lib/systemd/system in /etc/systemd/system.
  • Behalten Sie die ursprünglichen Dateinamen bei.
  1. Bearbeiten Sie die Kopien in /etc/systemd/system.
  2. Mit dem Kommando systemd-delta erhalten Sie einen Überblick über Ihre Konfigurationsänderungen.
  • Hiermit werden Konfigurationsdateien verglichen und ermittelt, die andere Konfigurationsdateien überschreiben.
  • Weitere Informationen finden Sie auf der man-Seite zu systemd-delta.

Die geänderten Dateien in /etc/systemd haben Vorrang vor den Originaldateien in /usr/lib/systemd/system, sofern die Dateinamen identisch sind.

Konvertieren von xinetd-Diensten in systemd

Seit der Version SUSE Linux Enterprise Desktop 15 wurde die xinetd-Infrastruktur entfernt.

  • In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte xinetd-Dienstdateien in systemd-Sockets konvertieren.

Für jede xinetd-Dienstdatei benötigen Sie mindestens zwei systemd-Unit-Dateien: die Socket-Datei ( *.socket ) und eine zugehörige Dienstdatei (*.service).

  • Die Socket-Datei weist systemd an, welcher Socket erstellt werden soll, und die Dienstdatei weist systemd an, welche ausführbare Datei gestartet werden soll.

Betrachten Sie das folgende Beispiel für eine xinetd-Dienstdatei: 

# cat /etc/xinetd.d/example
service example
{
 socket_type = stream
 protocol = tcp
 port = 10085
 wait = no
 user = user
 group = users
 groups = yes
 server = /usr/libexec/example/exampled
 server_args = -auth=bsdtcp exampledump
 disable = no
}

Zum Konvertieren in systemd benötigen Sie die folgenden beiden Dateien: 

# cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target
root # cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

Eine vollständige Liste der Socket- und Dienstdateioptionen für systemd finden Sie auf den man-Seiten zu systemd.socket und systemd.service (man 5 systemd.socket, man 5 systemd.service).

Erstellen von „Drop-in-Dateien“

Wenn eine Konfigurationsdatei nur um wenige Zeilen ergänzt oder nur ein kleiner Teil daraus geändert werden soll, können Sie sogenannte „Drop-in-Dateien“ verwenden.

  • Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.

Um beispielsweise einen einzigen Wert für den Dienst foobar in /usr/lib/systemd/system/ foobar.service zu ändern, gehen Sie wie folgt vor: # Erstellen Sie ein Verzeichnis mit dem Namen /etc/systemd/system/FOOBAR.service.d/.

Beachten Sie das Suffix .d.

  • Ansonsten muss der Name des Verzeichnisses mit dem Namen des Dienstes übereinstimmen, der mit der Drop-in-Datei gepatcht werden soll.
  1. Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen whatevermodification.conf.

Diese Datei darf nur eine Zeile mit dem zu ändernden Wert enthalten.

  1. Speichern Sie Ihre Änderungen in die Datei.
  • Die Datei wird als Erweiterung der Originaldatei verwendet.

Erstellen von benutzerdefinierten Zielen

Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können.

  • Mit systemd können Sie beliebig viele benutzerdefinierte Ziele erstellen.
  • Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise graphical.target. # Kopieren Sie die Konfigurationsdatei /usr/lib/systemd/system/graphical.target in /etc/systemd/system/MEIN_ZIEL.target und passen Sie sie nach Bedarf an.
  1. Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen („harten“) Abhängigkeiten für das Ziel.
  • Um auch die erwünschten („weichen“) Abhängigkeiten abzudecken, erstellen Sie ein Verzeichnis mit dem Namen /etc/systemd/system/MEIN_ZIEL.target.wants.
  1. Legen Sie für jeden erwünschten Dienst einen symbolischen Link von /usr/lib/systemd/system in /etc/systemd/system/MEIN_ZIEL.target.wants an.
  2. Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die systemd-Konfiguration neu.
  • Damit wird das neue Ziel verfügbar:
# systemctl daemon-reload

Erweiterte Nutzung

In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren.

Bereinigen von temporären Verzeichnissen

systemd unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse.

  • Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. tmpfiles.d (verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien /etc/tmpfiles.d/*.conf, /run/tmpfiles.d/*.conf und /usr/lib/tmpfiles.d/*.conf aus.
  • Die Konfiguration in /etc/tmpfiles.d/*.conf hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In /usr/lib/tmpfiles.d/*.conf speichern die Pakete die Konfigurationsdateien.)

Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann.

  • Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben:
Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

So rufen Sie den Status aus dem tmpfile-Zeitgeber ab: 

# systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
  Docs: man:tmpfiles.d(5)
        man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter man 5 tmpfiles.d.

Systemprotokoll

In wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen.

  • Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt.
  • Sie können auch auf das gesamte von systemd geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen.
  • Mit dem Befehl journalctl zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen.
  • Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter man 1 journalctl.

Aufnahmen

Mit dem Subkommando isolate können Sie den aktuellen Status von systemd als benannten Snapshot speichern und später wiederherstellen.

  • Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können.
  • Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht.
  • Der Snapshot-Name muss auf .snapshot enden.

Erstellen eines Snapshots 

# systemctl snapshot MY_SNAPSHOT.snapshot

Löschen eines Snapshots 

# systemctl delete MY_SNAPSHOT.snapshot

Anzeigen eines Snapshots 

# systemctl show MY_SNAPSHOT.snapshot

Aktivieren eines Snapshots 

# systemctl isolate MY_SNAPSHOT.snapshot

Laden der Kernelmodule

Mit systemd können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in /etc/modules-load.d.

  • Die Datei sollte den Namen MODUL.conf haben und den folgenden Inhalt aufweisen:
# load module  MODULE at boot time
MODULE

Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter /usr/lib/modules-load.d installiert.

  • Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter /etc/modules-load.d Vorrang.

Weitere Informationen finden Sie auf der man-Seite modules-load.d(5).

Ausführen von Aktionen vor dem Laden eines Dienstes

Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in /etc/init.d/before.local festgelegt werden.

  • Dieses Verfahren wird in systemd nicht mehr unterstützt.
  • Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:

Laden der Kernelmodule

Erstellen Sie eine Drop-in-Datei im Verzeichnis /etc/modules-load.d (Syntax siehe man modules-load.d).

Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers

Erstellen Sie eine Drop-in-Datei in /etc/tmpfiles.d (Syntax siehe man tmpfiles.d).

Weitere Aufgaben

Erstellen Sie eine Systemdienstdatei (beispielsweise /etc/systemd/system/before.service) anhand der folgenden Schablone: 

[Unit]
Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=YOUR_COMMAND
 # beware, executable is run directly, not through a shell, check the man pages
 # systemd.service and systemd.unit for full syntax
[Install]
 # target in which to start the service
WantedBy=multi-user.target
 #WantedBy=graphical.target

Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als root): 

# systemctl daemon-reload
# systemctl enable before

Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen: 

# systemctl daemon-reload

Kernel-Steuergruppen (cgroups)

Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde.

  • Einige Dienste (z. B.  Apache) erzeugen zahlreiche externe Prozesse (z. B.  CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen.
  • Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich.
  • Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf.
  • einige untergeordnete Dienste weiterhin aktiv.

Bei systemd wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist.

  • cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden.
  • Die cgroups werden dabei nach dem jeweiligen Dienst benannt.
  • Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.

Mit dem Kommando systemd-cgls erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:

Auflisten aller Prozesse, die zu einem Dienst gehören
root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server
[...]
└─system.slice
 ├─systemd-hostnamed.service
 │ └─17616 /usr/lib/systemd/systemd-hostnamed
 ├─cron.service
 │ └─1689 /usr/sbin/cron -n
 ├─postfix.service
 │ ├─ 1676 /usr/lib/postfix/master -w
 │ ├─ 1679 qmgr -l -t fifo -u
 │ └─15590 pickup -l -t fifo -u
 ├─sshd.service
 │ └─1436 /usr/sbin/sshd -D

[...]

Weitere Informationen zu cpgroups finden Sie in [Fixme]

Beenden von Diensten (Senden von Signalen)

Wie in erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden.

  • Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste.
  • Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.

Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, so dass Sie ein Signal zu diesen Prozessen senden können.

  • Mit Use systemctl kill senden Sie die Signale an die Dienste.
  • Eine Liste der verfügbaren Signale finden Sie in man 7 signals.

Senden von SIGTERM an einen Dienst

SIGTERM ist das standardmäßig gesendete Signal. 

# systemctl kill MY_SERVICE

Senden von SIGNAL an einen Dienst

Mit der Option -s legen Sie das zu sendende Signal fest. 

# systemctl kill -s SIGNAL MY_SERVICE

Auswählen von Prozessen

Standardmäßig sendet das Kommando kill das Signal an alle Prozesse der angegebenen cgroup.

  • Sie können dies jedoch auf den Prozess control oder main beschränken.
  • Damit können Sie beispielsweise das Neuladen der Konfiguration eines Dienstes mit dem Signal SIGHUP erzwingen:
# systemctl kill -s SIGHUP --kill-who=main MY_SERVICE

Warnung: Beenden oder Neustarten des D-BUS-Dienstes wird nicht unterstützt
Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. dbus ist zwar ein eigenständiger Daemon, bildet jedoch auch einen wesentlichen Bestandteil der Initialisierungsinfrastruktur.

Das Beenden von dbus oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten.

  • Hiermit wird die systemd-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd-Funktionen unbrauchbar werden.

Das Beenden oder Neustarten von dbus wird daher weder empfohlen noch unterstützt.

Fehlersuche für Dienste

Standardmäßig ist die Ausgabe von systemd auf ein Minimum beschränkt.

  • Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe.
  • Bei einem Fehler wird eine kurze Fehlermeldung angezeigt.
  • Mit systemctl status können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.

systemd umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden.

  • Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen.
  • Das Kommando status hat eine ähnliche Funktion wie tail und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.

Anzeigen von Fehlern beim Starten von Diensten

Wenn ein Dienst nicht gestartet wird, erhalten Sie mit systemctl status MEIN_DIENST eine ausführliche Fehlermeldung: 

# systemctl start apache2
Job failed.
  • See system journal and 'systemctl status' for details.
root # systemctl status apache2
  Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
  Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago
  Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
  CGroup: name=systemd:/system/apache2.service

Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>

Anzeigen der letzten n Dienstmeldungen

Standardmäßig zeigt das Subkommando status die letzten zehn Meldungen an, die ein Dienst ausgegeben hat.

  • Mit dem Parameter --lines=n legen Sie eine andere Anzahl fest:
# systemctl status chronyd
# systemctl --lines=20 status chronyd

Anzeigen von Dienstmeldungen im Anhängemodus

Mit der Option „--follow“ erhalten Sie einen Live-Stream mit Dienstmeldungen; diese Option entspricht tail -f: 

# systemctl --follow status chronyd

Ausgabeformat der Meldungen

Mit dem Parameter --output=mode legen Sie das Ausgabeformat für die Dienstmeldungen fest.

  • Die wichtigsten Modi sind:

short

Das Standardformat.

  • Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.

verbose

Vollständige Ausgabe mit sämtlichen Feldern.

cat

Kurze Ausgabe ohne Zeitstempel.


Abgerufen von „https://wiki.foxtom.de/index.php?title=Diskussion:Systemd&oldid=112350“