Systemd: Unterschied zwischen den Versionen

Aus Foxwiki
KKeine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(85 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== 13 Der Daemon systemd ==
'''systemd''' - [[Init-System]] und Systemmanager


Das Programm <tt>systemd</tt> trägt die Prozess-ID 1. Hiermit wird das System in der erforderlichen Form initialisiert. <tt>systemd</tt> wird direkt vom Kernel gestartet und widersteht dem Signal&nbsp;9, das in der Regel Prozesse beendet. Alle anderen Programme werden entweder direkt von systemd oder von einem seiner untergeordneten Prozesse gestartet.
{| class="wikitable options"
 
Systemd ersetzt den System V init-Daemon. <tt>systemd</tt> ist mit System V init uneingeschränkt kompatibel (init-Skripten werden unterstützt). Einer der wichtigsten Vorteile von systemd ist die deutliche Beschleunigung des Bootvorgangs, da die Dienststarts konsequent parallel ausgeführt werden. Darüber hinaus startet systemd einen Dienst nur dann, wenn er tatsächlich benötigt wird. Deamons werden nicht in jedem Fall beim Booten gestartet, sondern erst dann, wenn sie erstmalig benötigt werden. systemd unterstützt außerdem Kernel-Steuergruppen (cgroups), das Erstellen von Snapshots, das Wiederherstellen des Systemstatus und vieles mehr. Weitere Informationen finden Sie in [http://www.freedesktop.org/wiki/Software/systemd/ http://www.freedesktop.org/wiki/Software/systemd/].
 
== Konzept  ==
 
=== 13.1.1 Grundlagen von systemd ===
 
systemd ist ein System- und Sitzungsmanager für Linux und ist mit System V- und LSB-init-Skripts kompatibel. Die wichtigsten Funktionen sind: * Konsequente Parallelisierung
* Starten von Diensten per Socket- und D-Bus-Aktivierung
* Starten der Daemons bei Bedarf
* Verfolgen der Prozesse, die Linux-cgroups nutzen
* Unterstützung für das Erstellen von Snapshots und Wiederherstellen des Systemstatus
* Einhängepunkte und Automount-Punkte
* Ausgereifte Dienststeuerlogik auf der Basis der Transaktionsabhängigkeiten
 
 
 
=== 13.1.2 Unit-Datei ===
 
Eine Unit-Konfigurationsdatei enthält Informationen zu einem Dienst, Socket, Gerät, Einhängepunkt, Automount-Punkt, einer Auslagerungsdatei oder Partition, einem Startziel, einem überwachten Dateisystempfad, einem von systemd gesteuerten und überwachten Zeitgeber, einem Snapshot eines temporären Systemstatus, einem Ressourcenverwaltungs-Slice oder einer Gruppe extern erstellter Prozesse. „Unit-Datei“ ist in systemd ein generischer Term für Folgendes: * Dienst.&nbsp; Informationen zu einem Prozess (z. B. Ausführung eines Daemon); Datei endet auf .service
* Ziele.&nbsp; Fassen Units zu Gruppen zusammen bzw. fungieren als Synchronisierungspunkte beim Starten; Datei endet auf .target
* Sockets.&nbsp; Informationen zu einem IPC- oder Netzwerk-Socket oder einem Dateisystem-FIFO, für die socketbasierte Aktivierung (wie <tt>inetd</tt>); Datei endet auf .socket
* Pfad.&nbsp; Dient als Auslöser von anderen Units (z. B. Ausführen eines Dienstes, wenn Dateien geändert werden); Datei endet auf .path
* Zeitgeber.&nbsp; Informationen zu einem gesteuerten Zeitgeber für die zeitgeberbasierte Aktivierung; Datei endet auf .timer
* Einhängepunkt.&nbsp; In der Regel automatisch durch den fstab-Generator erzeugt; Datei endet auf .mount
* Automount-Punkt.&nbsp; Informationen zu einem Dateisystem-Automount-Punkt; Datei endet auf .automount
* Swap.&nbsp; Informationen zu einem Auslagerungsgerät oder einer Auslagerungsdatei für das Arbeitsspeicher-Paging; Datei endet auf .swap
* Gerät.&nbsp; Informationen zu einer Geräte-Unit in der Geräte-Baumstruktur sysfs/udev(7); Datei endet auf .device
* Bereich/Slice.&nbsp; Konzept für die hierarchische Verwaltung von Ressourcen einer Prozessgruppe; Datei endet auf .scope/.slice
 
 
 
Weitere Informationen zu systemd.unit finden Sie unter [http://www.freedesktop.org/software/systemd/man/systemd.unit.html http://www.freedesktop.org/software/systemd/man/systemd.unit.html].
 
== 13.2 Grundlegende Verwendung ==
 
Im System V-init-System werden Dienste mit mehreren Kommandos verarbeitet – mit init-Skripten, <tt>insserv</tt>, <tt>telinit</tt> und anderen. systemd erleichtert die Dienstverwaltung, da ein einziges Kommando die meisten Dienstverarbeitungsaufgaben abdeckt: <tt>systemctl</tt>. Hierbei gilt die Syntax „Kommando plus Subkommando“ wie bei <tt>git</tt> oder <tt>zypper</tt>:
 
systemctl ''GENERAL OPTIONS'' ''SUBCOMMAND'' ''SUBCOMMAND OPTIONS''
 
Vollständige Anweisungen finden Sie in <tt>man 1 systemctl</tt>.
 
====== Tipp: Terminalausgabe und Bash-Vervollständigung ======
 
Wenn die Ausgabe an ein Terminal geht (und nicht an eine Pipe oder Datei usw.), senden die systemd-Kommandos standardmäßig eine ausführliche Ausgabe an einen Pager. Mit der Option <tt>--no-pager</tt> deaktivieren Sie den Paging-Modus.
 
systemd unterstützt außerdem die Bash-Vervollständigung. Hierbei geben Sie die ersten Buchstaben eines Subkommandos ein und drücken dann →|, um es automatisch zu vervollständigen. Diese Funktion ist nur in der <tt>Bash</tt>-Shell verfügbar und das Paket <tt>bash-completion</tt> muss installiert sein.
 
=== 13.2.1 Verwalten von Diensten auf einem laufenden System ===
 
Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (<tt>start</tt>, <tt>stop</tt> usw.). Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:
 
<div style="margin-left:0cm;margin-right:0cm;">systemd</div>
 
systemctl reload|restart|start|status|stop|''...'' ''MY_SERVICE(S)''
 
<div style="margin-left:0cm;margin-right:0cm;">System V-init</div>
 
rc''MY_SERVICE(S)'' reload|restart|start|status|stop|''...''
 
Mit systemd können Sie mehrere Dienste gleichzeitig verwalten. Im Gegensatz zu System V-init, bei dem die init-Skripts einzeln nacheinander ausgeführt werden, führen Sie ein einziges Kommando aus, beispielsweise:
 
tux > sudo systemctl start ''MY_1ST_SERVICE'' ''MY_2ND_SERVICE''
 
So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab:
 
tux > sudo systemctl list-unit-files --type=service
 
Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd und System V-init:
 
====== Tabelle 13.1: Befehle zur Diensteverwaltung [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.6.6.9 #] ======
 
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''Aufgabe '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''systemd-Kommando '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''System V-init-Kommando '''
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Starten.&nbsp;
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | start
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | start
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Stoppen.&nbsp;
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | stop
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | stop
|- style="border:none;padding:0.049cm;"
|| Neu starten.&nbsp; Fährt Dienste herunter und startet sie dann neu. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.
|| restart
|| restart
|- style="border:none;padding:0.049cm;"
|| Bedingt neu starten.&nbsp; Startet Dienste neu, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.
|| try-restart
|| try-restart
|- style="border:none;padding:0.049cm;"
|| Neu laden.&nbsp; Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen. Anwendungsbeispiel: Weisen Sie Apache an, eine bearbeitete Konfigurationsdatei <tt>httpd.conf</tt> neu zu laden. Nicht alle Dienste unterstützen das Neuladen.
|| reload
|| reload
|- style="border:none;padding:0.049cm;"
|| Neu laden oder neu starten.&nbsp; Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.
|| reload-or-restart
|| n/a
|- style="border:none;padding:0.049cm;"
|| Bedingt neu laden oder neu starten.&nbsp; Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.
|| reload-or-try-restart
|| n/a
|- style="border:none;padding:0.049cm;"
|| Ausführliche Statusinformationen abrufen.&nbsp; Zeigt Informationen zum Dienststatus. Das Kommando <tt>systemd</tt> bietet Details wie Beschreibung, ausführbare Datei, Status, cgroup und zuletzt durch den Dienst ausgegebene Meldungen (siehe [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-basics-services-debugging Abschnitt 13.6.8, „Fehlersuche für Dienste“]). Die Detailtiefe bei System V-init ist von Dienst zu Dienst unterschiedlich.
|| status
|| status
|- style="border:none;padding:0.049cm;"
|| Kurze Statusinformationen abrufen.&nbsp; Gibt an, ob Dienste aktiv sind oder nicht.
|| is-active
|| status
|-
|}
 
 
=== 13.2.2 Dienste dauerhaft aktivieren/deaktivieren ===
 
Mit den Dienstverwaltungskommandos im vorangegangenen Abschnitt können Sie die Dienste für die aktuelle Sitzung bearbeiten. Mit systemd können Sie Dienste außerdem dauerhaft aktivieren oder deaktivieren, so dass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Kommandozeile tun.
 
==== 13.2.2.1 Aktivieren/Deaktivieren von Diensten über die Kommandozeile ====
 
Die folgende Tabelle zeigt die wichtigsten Aktivierungs- und Deaktivierungskommandos für systemd und System V-init:
 
====== Wichtig: Service starten ======
 
Wenn ein Dienst über die Kommandozeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Soll ein Dienst nach dem Aktivieren sofort gestartet werden, führen Sie explizit <tt>systemctl start ''MEIN_DIENST''</tt> oder <tt>rc ''MEIN_DIENST'' start</tt> aus.
 
====== Tabelle 13.2: Kommandos zum Aktivieren und Deaktivieren von Diensten [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.6.7.3.4 #] ======
 
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''Aufgabe '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>'''systemd-Kommando</tt> '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''System V-init-Kommando '''
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Aktivieren.&nbsp;
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>systemctl enable ''MEIN(E)_DIENST(E)''</tt>
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>insserv ''MEIN(E)_DIENST(E)''</tt>, <tt>chkconfig -a ''MEIN(E)_DIENST(E)''</tt>
|- style="border:none;padding:0.049cm;"
|| Deaktivieren.&nbsp;
|| <tt>systemctl disable ''MEIN(E)_DIENST(E)''.service</tt>
|| <tt>insserv -r ''MEIN(E)_DIENST(E)''</tt>, <tt>chkconfig -d ''MEIN(E)_DIENST(E)''</tt>
|- style="border:none;padding:0.049cm;"
|| Überprüfen.&nbsp; Zeigt an, ob ein Dienst aktiviert ist oder nicht.
|| <tt>systemctl is-enabled ''MEIN_DIENST''</tt>
|| <tt>chkconfig ''MEIN_DIENST''</tt>
|- style="border:none;padding:0.049cm;"
|| Erneut aktivieren.&nbsp; Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll.
|| <tt>systemctl reenable ''MEIN_DIENST''</tt>
|| n/v
|- style="border:none;padding:0.049cm;"
|| Maskierung.&nbsp; Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst vollständig deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden.
|| <tt>systemctl mask ''MEIN_DIENST''</tt>
|| n/v
|- style="border:none;padding:0.049cm;"
|| Demaskieren.&nbsp; Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde.
|| <tt>systemctl unmask ''MEIN_DIENST''</tt>
|| n/v
|-
|}
 
 
== 13.3 Systemstart und Zielverwaltung ==
 
Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von systemd verwaltet. Von diesem Gesichtspunkt aus kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.
 
=== 13.3.1 Ziele im Vergleich zu Runlevels ===
 
Bei System V-init wurde das System in ein sogenanntes „Runlevel“ gebootet. Ein Runlevel definiert, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Die Runlevels sind numeriert. Die bekanntesten Runlevels sind <tt>0</tt> (System herunterfahren), <tt>3</tt> (Mehrbenutzermodus mit Netzwerk) und <tt>5</tt> (Mehrbenutzermodus mit Netzwerk und Anzeigemanager).
 
systemd führt mit den sogenannten „Ziel-Units“ ein neues Konzept ein. Dennoch bleibt die Kompatibilität mit dem Runlevel-Konzept uneingeschränkt erhalten. Die Ziel-Units tragen Namen statt Zahlen und erfüllen bestimmte Zwecke. Mit den Zielen <tt>local-fs.target</tt> und <tt>swap.target</tt> werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.
 
Das Ziel <tt>graphical.target</tt> stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel 5. Komplexe Ziele wie <tt>graphical.target</tt> fungieren als „Metaziele“, in denen eine Teilmenge anderer Ziele vereint ist. Mit systemd können Sie problemlos vorhandene Ziele kombinieren und so benutzerdefinierte Ziele bilden. Damit bietet dieses Kommando eine hohe Flexibilität.
 
Die nachfolgende Liste zeigt die wichtigsten systemd-Ziel-Units. Eine vollständige Liste finden Sie in <tt>man 7 systemd.special</tt>.
 
====== Ausgewählte systemd-Ziel-Units [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.3.6 #] ======
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>default.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Das Ziel, das standardmäßig gebootet wird. Kein „reales“ Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie <tt>graphic.target</tt>. Kann über YaST dauerhaft geändert werden (siehe [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-runlevel-edit Abschnitt 13.4, „Verwalten von Services mit YaST“]). Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parameter <tt>systemd.unit=''MEIN_ZIEL.target''</tt> am Bootprompt ein. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>emergency.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Startet eine Notfall-Shell über die Konsole. Dieses Kommando darf nur an der Boot-Eingabeaufforderung im Format <tt>systemd.unit=emergency.target</tt> verwendet werden. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>graphical.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>halt.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Fährt das System herunter. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>mail-transfer-agent.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>multi-user.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Startet ein Mehrbenutzersystem mit Netzwerk. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>reboot.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Bootet das System neu. </div>
 
<div style="margin-left:0cm;margin-right:0cm;"><tt>rescue.target</tt> </div>
 
<div style="margin-left:1cm;margin-right:0cm;">Startet ein Einzelbenutzersystem ohne Netzwerk. </div>
 
Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd besondere Ziele mit der Bezeichnung <tt>runlevel''X''.target</tt>, denen die entsprechenden, mit ''X'' numerierten Runlevels zugeordnet sind.
 
Mit dem Kommando <tt>systemctl get-default</tt> ermitteln Sie das aktuelle Ziel.
 
====== Tabelle 13.3: System V-Runlevels und systemd-Ziel-Units [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.3.9 #] ======
 
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|- style="border:none;padding:0.049cm;"
| align=center| '''System V-Runlevel '''
| align=center| <tt>'''systemd</tt>-Ziel '''
| align=center| '''Beschreibung '''
|- style="border:none;padding:0.049cm;"
|| 0
|| <tt>runlevel0.target</tt>, <tt>halt.target</tt>, <tt>poweroff.target</tt>
|| System herunterfahren
|- style="border:none;padding:0.049cm;"
|| 1, S
|| <tt>runlevel1.target</tt>, <tt>rescue.target</tt>,
|| Einzelbenutzermodus
|- style="border:none;padding:0.049cm;"
|| 2
|| <tt>runlevel2.target</tt>, <tt>multi-user.target</tt>,
|| Lokaler Mehrbenutzermodus ohne entferntes Netzwerk
|- style="border:none;padding:0.049cm;"
|| 3
|| <tt>runlevel3.target</tt>, <tt>multi-user.target</tt>,
|| Mehrbenutzer-Vollmodus mit Netzwerk
|- style="border:none;padding:0.049cm;"
|| 4
|| <tt>runlevel4.target</tt>
|| Nicht verwendet/benutzerdefiniert
|- style="border:none;padding:0.049cm;"
|| 5
|| <tt>runlevel5.target</tt>, <tt>graphical.target</tt>,
|| Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager
|- style="border:none;padding:0.049cm;"
|| 6
|| <tt>runlevel6.target</tt>, <tt>reboot.target</tt>,
|| Systemneustart
|-
|}
 
 
====== Wichtig: systemd ignoriert /etc/inittab ======
 
Die Runlevels in einem System V-init-System werden in <tt>/etc/inittab</tt> konfiguriert. Bei systemd wird diese Konfiguration ''nicht'' verwendet. Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-custom-targets Abschnitt 13.5.3, „Erstellen von benutzerdefinierten Zielen“].
 
==== 13.3.1.1 Kommandos zum Ändern von Zielen ====
 
Mit den folgenden Kommandos arbeiten Sie mit den Ziel-Units:
 
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''Aufgabe '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''systemd-Kommando '''
| align=center style="border-top:0.75pt double #808080;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | '''System V-init-Kommando '''
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Aktuelles Ziel/Runlevel ändern
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>systemctl isolate</tt> ''MEIN_ZIEL''.target
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>telinit</tt> ''X''
|-
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Zum standardmäßigen Ziel/Runlevel wechseln
| Beschreibung || [[Systemd/Beschreibung]]
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>systemctl default</tt>
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | n/v
|-
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Aktuelles Ziel/Runlevel abrufen
| Installation || [[Systemd/Installation]]
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>systemctl list-units --type=target</tt>
 
Bei systemd sind in der Regel mehrere Ziele aktiv. Mit diesem Kommando werden alle derzeit aktiven Ziele aufgelistet.
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | <tt>who -r</tt>
 
oder
 
<tt>runlevel</tt>
|-
|-
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.75pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Standard-Runlevel dauerhaft ändern
| Syntax || [[Systemd/Syntax]]
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Verwenden Sie die Dienste-Verwaltung, oder führen Sie das folgende Kommando aus:
 
<tt>ln -sf /usr/lib/systemd/system/</tt> ''MEIN_ZIEL''.target /etc/systemd/system/default.target
| style="border-top:none;border-bottom:0.15pt double #808080;border-left:0.15pt double #808080;border-right:0.75pt double #808080;padding:0.049cm;" | Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile
 
<tt>id:</tt> ''X'':initdefault:
 
in <tt>/etc/inittab</tt>
|- style="border:none;padding:0.049cm;"
|| Standard-Runlevel für den aktuellen Bootprozess ändern
|| Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:
 
<tt>systemd.unit=</tt> ''MEIN_ZIEL''.target
|| Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein.
|- style="border:none;padding:0.049cm;"
|| Abhängigkeiten für ein Ziel/Runlevel anzeigen
|| <tt>systemctl show -p "Requires" </tt>''MEIN_ZIEL''.target
 
<tt>systemctl show -p "Wants" </tt>''MEIN_ZIEL''.target
 
„Requires“ (Benötigt) zeigt eine Liste der harten Abhängigkeiten (die in jedem Fall aufgelöst werden müssen), „Wants“ (Erwünscht) dagegen eine Liste der weichen Abhängigkeiten (die nach Möglichkeit aufgelöst werden).
|| n/v
|-
|-
|}
| Anwendung || [[Systemd/Anwendung]]
 
 
=== 13.3.2 Fehlersuche beim Systemstart ===
 
systemd bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Dienste mit dem jeweiligen Status prüfen (ohne durch <tt>/varlog/</tt> blättern zu müssen). Mit systemd können Sie zudem den Startvorgang scannen und so ermitteln, wie lang das Starten der einzelnen Dienste dauert.
 
==== 13.3.2.1 Prüfen des Startvorgangs der Dienste ====
 
Mit dem Kommando <tt>systemctl</tt> erzeugen Sie eine Liste aller Dienste, die seit dem Booten des Systems gestartet wurden. Hier werden alle aktiven Dienste wie im nachstehenden (gekürzten) Beispiel aufgeführt. Mit <tt>systemctl status ''MEIN_DIENST''</tt> erhalten Sie weitere Informationen zu einem bestimmten Dienst.
 
====== Beispiel 13.1: Liste der aktiven Dienste [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.4.3.3 #] ======
 
root # systemctl
UNIT                        LOAD  ACTIVE SUB      JOB DESCRIPTION
[...]
iscsi.service              loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service  loaded active exited    Create list of required s+
libvirtd.service            loaded active running  Virtualization daemon
nscd.service                loaded active running  Name Service Cache Daemon
chronyd.service            loaded active running  NTP Server Daemon
polkit.service              loaded active running  Authorization Manager
postfix.service            loaded active running  Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service            loaded active running  System Logging Service
[...]
LOAD  <nowiki>= Reflects whether the unit definition was properly loaded.</nowiki>
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    <nowiki>= The low-level unit activation state, values depend on unit type.</nowiki>
 
161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
 
Soll die Ausgabe auf Dienste beschränkt werden, die nicht gestartet werden konnten, geben Sie die Option <tt>--failed</tt> an:
 
====== Beispiel 13.2: Liste der fehlerhaften Dienste [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.4.3.5 #] ======
 
root # systemctl --failed
UNIT                  LOAD  ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed    apache
NetworkManager.service loaded failed failed    Network Manager
plymouth-start.service loaded failed failed    Show Plymouth Boot Screen
 
[...]
 
==== 13.3.2.2 Fehlersuche für die Startzeit ====
 
Mit dem Kommando <tt>systemd-analyze</tt> führen Sie die Fehlersuche für die Startzeit durch. Hiermit werden der Gesamtzeitaufwand für den Startvorgang sowie eine Liste der beim Starten angeforderten Dienste angezeigt. Auf Wunsch kann auch eine SVG-Grafik erstellt werden, aus der hervorgeht, wie lange der Start der Dienste im Vergleich zu den anderen Diensten dauerte.
 
<div style="margin-left:0cm;margin-right:0cm;">Auflisten der Startzeit des Systems</div>
 
root # systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
 
<div style="margin-left:0cm;margin-right:0cm;">Auflisten der Startzeit der Dienste</div>
 
root # systemd-analyze blame
  6472ms systemd-modules-load.service
  5833ms remount-rootfs.service
  4597ms network.service
  4254ms systemd-vconsole-setup.service
  4096ms postfix.service
  2998ms xdm.service
  2483ms localnet.service
  2470ms SuSEfirewall2_init.service
  2189ms avahi-daemon.service
  2120ms systemd-logind.service
  1080ms chronyd.service
[...]
    75ms fbset.service
    72ms purge-kernels.service
    47ms dev-vda1.swap
    38ms bluez-coldplug.service
    35ms splash_early.service
 
<div style="margin-left:0cm;margin-right:0cm;">Grafische Darstellung der Startzeit der Dienste</div>
 
root # systemd-analyze plot > jupiter.example.com-startup.svg
 
 
==== 13.3.2.3 Prüfen des gesamten Startvorgangs ====
 
Mit den obigen Kommandos prüfen Sie die gestarteten Dienste und den Zeitaufwand für den Start. Wenn Sie detailliertere Informationen benötigen, können Sie <tt>systemd</tt> anweisen, den gesamten Startvorgang ausführlich zu protokollieren. Geben Sie hierzu die folgenden Parameter an der Boot-Eingabeaufforderung ein:
 
systemd.log_level=debug systemd.log_target=kmsg
 
<tt>systemd</tt> schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer. Diesen Puffer zeigen Sie mit <tt>dmesg</tt> an:
 
tux > dmesg -T | less
 
=== 13.3.3 System V-Kompatibilität ===
 
systemd ist mit System V kompatibel, sodass Sie vorhandene System V-init-Skripte weiterhin nutzen können. Es gibt allerdings mindestens ein bekanntes Problem, bei dem ein System V-init-Skript nicht ohne Weiteres mit systemd zusammenarbeitet: Wenn Sie einen Dienst als ein anderer Benutzer über <tt>su</tt> oder <tt>sudo</tt> in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.
 
Wenn Sie den Benutzer mit <tt>su</tt> oder <tt>sudo</tt> ändern, wird eine PAM-Sitzung gestartet. Diese Sitzung wird beendet, sobald das init-Skript abgeschlossen ist. Als Folge wird auch der Service, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor: # Erstellen Sie einen Service-Datei-Wrapper mit demselben Namen wie das init-Skript und der Dateinamenerweiterung <tt>.service</tt>: <br/>[Unit]<br/>Description=''DESCRIPTION''<br/>After=network.target<br/>
[Service]<br/>User=''USER''<br/>Type=forking1<br/>PIDFile=''PATH TO PID FILE''[https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#co-service-wrapper-type 1]<br/>ExecStart=''PATH TO INIT SCRIPT'' start<br/>ExecStop=''PATH TO INIT SCRIPT'' stop<br/>ExecStopPost=/usr/bin/rm -f ''PATH TO PID FILE''[https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#co-service-wrapper-type 1]<br/>
[Install]<br/>WantedBy=multi-user.target2<br/>Ersetzen Sie alle Werte in ''GROSSBUCHSTABEN'' durch die entsprechenden Werte.
 
 
 
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|- style="border:none;padding:0.049cm;"
|| [[#co-service-wrapper-type|1]]
|| Optional; nur zu verwenden, wenn mit dem init-Skript ein Daemon gestartet wird.
|- style="border:none;padding:0.049cm;"
|| [[#co-service-wrapper-target|2]]  
|| <tt>multi-user.target</tt> startet ebenfalls das init-Skript, wenn Sie in <tt>graphical.target</tt> booten. Falls der Start nur beim Booten in den Display-Manager erfolgen soll, verwenden Sie hier <tt>graphical.target</tt>.
|-
|-
| Konfiguration || [[Systemd/Konfiguration]]
|}
|}
# Starten Sie den Daemon mit <tt>systemctl start ''ANWENDUNG''</tt>.
== Anpassen von systemd ==
====== Warnung: 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.
=== 13.5.1 Anpassen von Unit-Dateien ===
Die systemd-Unit-Dateien befinden sich in<tt>/usr/lib/systemd/system</tt>. 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>. 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>.
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.
==== 13.5.1.1 Konvertieren von xinetd-Diensten in systemd ====
Seit der Version SUSE Linux Enterprise Desktop&nbsp;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.
Für jede <tt>xinetd</tt>-Dienstdatei benötigen Sie mindestens zwei <tt>systemd</tt>-Unit-Dateien: die Socket-Datei (<tt><nowiki>*.socket</nowiki></tt>) und eine zugehörige Dienstdatei (<tt><nowiki>*.service</nowiki></tt>). 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.
Betrachten Sie das folgende Beispiel für eine <tt>xinetd</tt>-Dienstdatei:
root # 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 <tt>systemd</tt> benötigen Sie die folgenden beiden Dateien:
root # 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 <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>).
=== 13.5.2 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 <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>. <br/>Beachten Sie das Suffix <tt>.d</tt>. 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>. <br/>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.
=== 13.5.3 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: <br/>tux > sudo systemctl daemon-reload
== 13.6 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 http://0pointer.de/blog/projects].
=== 13.6.1 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.)
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:
tux > sudo 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 <tt>man 5 tmpfiles.d</tt>.
=== 13.6.2 Systemprotokoll ===
In [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-basics-services-debugging Abschnitt 13.6.8, „Fehlersuche für Dienste“] 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>.
=== 13.6.3 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.
<div style="margin-left:0cm;margin-right:0cm;">Erstellen eines Snapshots</div>
tux > sudo systemctl snapshot ''MY_SNAPSHOT''.snapshot
<div style="margin-left:0cm;margin-right:0cm;">Löschen eines Snapshots</div>
tux > sudo systemctl delete ''MY_SNAPSHOT''.snapshot
<div style="margin-left:0cm;margin-right:0cm;">Anzeigen eines Snapshots</div>
tux > sudo systemctl show ''MY_SNAPSHOT''.snapshot
<div style="margin-left:0cm;margin-right:0cm;">Aktivieren eines Snapshots</div>
tux > sudo systemctl isolate ''MY_SNAPSHOT''.snapshot
=== 13.6.4 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:
<nowiki># load module </nowiki>''MODULE'' at boot time
''MODULE''
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.
Weitere Informationen finden Sie auf der man-Seite <tt>modules-load.d(5)</tt>.
=== 13.6.5 Ausführen von Aktionen vor dem Laden eines Dienstes ===
Bei System&nbsp;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:
<div style="margin-left:0cm;margin-right:0cm;">Laden der Kernelmodule</div>
<div style="margin-left:1cm;margin-right:0cm;">Erstellen Sie eine Drop-in-Datei im Verzeichnis <tt>/etc/modules-load.d</tt> (Syntax siehe <tt>man modules-load.d</tt>). </div>
<div style="margin-left:0cm;margin-right:0cm;">Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers </div>
<div style="margin-left:1cm;margin-right:0cm;">Erstellen Sie eine Drop-in-Datei in <tt>/etc/tmpfiles.d</tt> (Syntax siehe <tt>man tmpfiles.d</tt>). </div>
<div style="margin-left:0cm;margin-right:0cm;">Weitere Aufgaben</div>
<div style="margin-left:1cm;margin-right:0cm;">Erstellen Sie eine Systemdienstdatei (beispielsweise <tt>/etc/systemd/system/before.service</tt>) anhand der folgenden Schablone: </div>
[Unit]
Before=''NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE''
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=''YOUR_COMMAND''
<nowiki># beware, executable is run directly, not through a shell, check the man pages</nowiki>
<nowiki># systemd.service and systemd.unit for full syntax</nowiki>
[Install]
<nowiki># target in which to start the service</nowiki>
WantedBy=multi-user.target
<nowiki>#WantedBy=graphical.target</nowiki>
<div style="margin-left:1cm;margin-right:0cm;">Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als <tt>root</tt>): </div>
tux > sudo systemctl daemon-reload
tux > sudo systemctl enable before
<div style="margin-left:1cm;margin-right:0cm;">Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen: </div>
tux > sudo systemctl daemon-reload
=== 13.6.6 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 <tt>systemd-cgls</tt> erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:
====== Beispiel 13.3: Auflisten aller Prozesse, die zu einem Dienst gehören [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.10.8.5 #] ======
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 [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-tuning-cgroups.html Chapter 9, ][https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-tuning-cgroups.html Kernel Control Groups].
=== 13.6.7 Beenden von Diensten (Senden von Signalen) ===
Wie in [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-advanced-cgroups Abschnitt 13.6.6, „Kernel-Steuergruppen (cgroups)“] 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>.
<div style="margin-left:0cm;margin-right:0cm;">Senden von <tt>SIGTERM</tt> an einen Dienst</div>
<div style="margin-left:1cm;margin-right:0cm;"><tt>SIGTERM</tt> ist das standardmäßig gesendete Signal. </div>
tux > sudo systemctl kill ''MY_SERVICE''
<div style="margin-left:0cm;margin-right:0cm;">Senden von ''SIGNAL'' an einen Dienst</div>
<div style="margin-left:1cm;margin-right:0cm;">Mit der Option <tt>-s</tt> legen Sie das zu sendende Signal fest. </div>
tux > sudo systemctl kill -s ''SIGNAL'' ''MY_SERVICE''
<div style="margin-left:0cm;margin-right:0cm;">Auswählen von Prozessen</div>
<div style="margin-left:1cm;margin-right:0cm;">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: </div>
tux > sudo 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&nbsp;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&nbsp;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.
=== 13.6.8 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.
<div style="margin-left:0cm;margin-right:0cm;">Anzeigen von Fehlern beim Starten von Diensten</div>
<div style="margin-left:1cm;margin-right:0cm;">Wenn ein Dienst nicht gestartet wird, erhalten Sie mit <tt>systemctl status ''MEIN_DIENST''</tt> eine ausführliche Fehlermeldung: </div>
root # 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>
<div style="margin-left:0cm;margin-right:0cm;">Anzeigen der letzten ''n'' Dienstmeldungen</div>
<div style="margin-left:1cm;margin-right:0cm;">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: </div>
tux > sudo systemctl status chronyd
tux > sudo systemctl --lines=20 status chronyd
<div style="margin-left:0cm;margin-right:0cm;">Anzeigen von Dienstmeldungen im Anhängemodus</div>
<div style="margin-left:1cm;margin-right:0cm;">Mit der Option „--follow“ erhalten Sie einen <tt>Live-Stream</tt> mit Dienstmeldungen; diese Option entspricht <tt>tail -f</tt>: </div>
tux > sudo systemctl --follow status chronyd
<div style="margin-left:0cm;margin-right:0cm;">Ausgabeformat der Meldungen</div>
<div style="margin-left:1cm;margin-right:0cm;">Mit dem Parameter <tt>--output=''mode''</tt> legen Sie das Ausgabeformat für die Dienstmeldungen fest. Die wichtigsten Modi sind: </div>
<div style="margin-left:0cm;margin-right:0cm;"><tt>short</tt> </div>
<div style="margin-left:1cm;margin-right:0cm;">Das Standardformat. Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an. </div>
<div style="margin-left:0cm;margin-right:0cm;"><tt>verbose</tt> </div>
<div style="margin-left:1cm;margin-right:0cm;">Vollständige Ausgabe mit sämtlichen Feldern. </div>
<div style="margin-left:0cm;margin-right:0cm;"><tt>cat</tt> </div>
<div style="margin-left:1cm;margin-right:0cm;">Kurze Ausgabe ohne Zeitstempel. </div>
== 13.7 Weitere Informationen ==
Weitere Informationen zu systemd finden Sie in folgenden Online-Quellen:
<div style="margin-left:0cm;margin-right:0cm;">Startseite</div>
<div style="margin-left:1cm;margin-right:0cm;">[http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd] </div>
<div style="margin-left:0cm;margin-right:0cm;">systemd für Administratoren</div>


<div style="margin-left:1cm;margin-right:0cm;">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 http://0pointer.de/blog/projects] zu finden. </div>
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Dokumentation ====


===== Man-Page =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
===== Weblinks =====


[[Kategorie:systemd]]


[[Kategorie:Linux:Systemd]]
</noinclude>

Aktuelle Version vom 6. November 2024, 12:40 Uhr