Systemd/Anwendung
Grundlegende Verwendung
Im System V-init-System werden Dienste mit mehreren Kommandos verarbeitet – mit init-Skripten, insserv, telinit und anderen.
- systemd erleichtert die Dienstverwaltung, da ein einziges Kommando die meisten Dienstverarbeitungsaufgaben abdeckt: systemctl.
- Hierbei gilt die Syntax „Kommando plus Subkommando“ wie bei git oder zypper:
systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS
Vollständige Anweisungen finden Sie in man 1 systemctl.
- 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 --no-pager 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 Bash-Shell verfügbar und das Paket bash-completion muss installiert sein.
Verwalten von Diensten auf einem laufenden System
Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (start, stop usw.).
- Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:
systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
System V-init
# rcMY_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:
# systemctl start MY_1ST_SERVICE MY_2ND_SERVICE
So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab:
# sudo systemctl list-unit-files --type=service
Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd und System V-init:
Befehle zur Diensteverwaltung
| Aufgabe | systemd-Kommando | System V-init-Kommando |
| Starten. | start | start |
| Stoppen. | stop | stop |
Neu starten. Fährt Dienste herunter und startet sie dann neu.
|
restart | restart |
Bedingt neu starten. Startet Dienste neu, wenn sie derzeit ausgeführt werden.
|
try-restart | try-restart |
Neu laden. Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen.
|
reload | reload |
Neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet.
|
reload-or-restart | n/a |
Bedingt neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden.
|
reload-or-try-restart | n/a |
Ausführliche Statusinformationen abrufen. Zeigt Informationen zum Dienststatus.
|
status | status |
| Kurze Statusinformationen abrufen. Gibt an, ob Dienste aktiv sind oder nicht. | is-active | status |
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.
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 systemctl start MEIN_DIENST oder rc MEIN_DIENST start aus.
Kommandos zum Aktivieren und Deaktivieren von Diensten
| Aufgabe | systemd-Kommando | System V-init-Kommando |
| Aktivieren. | systemctl enable MEIN(E)_DIENST(E) | insserv MEIN(E)_DIENST(E), chkconfig -a MEIN(E)_DIENST(E) |
| Deaktivieren. | systemctl disable MEIN(E)_DIENST(E).service | insserv -r MEIN(E)_DIENST(E), chkconfig -d MEIN(E)_DIENST(E) |
| Überprüfen. Zeigt an, ob ein Dienst aktiviert ist oder nicht. | systemctl is-enabled MEIN_DIENST | chkconfig MEIN_DIENST |
Erneut aktivieren. Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder.
|
systemctl reenable MEIN_DIENST | n/v |
Maskierung. Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden.
|
systemctl mask MEIN_DIENST | n/v |
| Demaskieren. Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde. | systemctl unmask MEIN_DIENST | n/v |
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.
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 0 (System herunterfahren), 3 (Mehrbenutzermodus mit Netzwerk) und 5 (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 local-fs.target und swap.target werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.
Das Ziel graphical.target stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel Komplexe Ziele wie graphical.target 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 man 7 systemd.special.
Ausgewählte systemd-Ziel-Units
default.target
Das Ziel, das standardmäßig gebootet wird.
- Kein „reales“ Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie graphic.target.
- Kann über YaST dauerhaft geändert werden.
- Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parameter systemd.unit=MEIN_ZIEL.target am Bootprompt ein.
emergency.target
Startet eine Notfall-Shell über die Konsole.
- Dieses Kommando darf nur an der Boot-Eingabeaufforderung im Format systemd.unit=emergency.target verwendet werden.
graphical.target
Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager.
halt.target
Fährt das System herunter.
mail-transfer-agent.target
Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind.
multi-user.target
Startet ein Mehrbenutzersystem mit Netzwerk.
reboot.target
Bootet das System neu.
rescue.target
Startet ein Einzelbenutzersystem ohne Netzwerk.
Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd besondere Ziele mit der Bezeichnung runlevelX.target, denen die entsprechenden, mit X numerierten Runlevels zugeordnet sind.
Mit dem Kommando systemctl get-default ermitteln Sie das aktuelle Ziel.
System V-Runlevels und systemd-Ziel-Units
| System V-Runlevel | systemd-Ziel | Beschreibung |
| 0 | runlevel0.target, halt.target, poweroff.target | System herunterfahren |
| 1, S | runlevel1.target, rescue.target, | Einzelbenutzermodus |
| 2 | runlevel2.target, multi-user.target, | Lokaler Mehrbenutzermodus ohne entferntes Netzwerk |
| 3 | runlevel3.target, multi-user.target, | Mehrbenutzer-Vollmodus mit Netzwerk |
| 4 | runlevel4.target | Nicht verwendet/benutzerdefiniert |
| 5 | runlevel5.target, graphical.target, | Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager |
| 6 | runlevel6.target, reboot.target, | Systemneustart |
Wichtig: systemd ignoriert /etc/inittab
Die Runlevels in einem System V-init-System werden in /etc/inittab konfiguriert.
- Bei systemd wird diese Konfiguration nicht verwendet.
- Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter.
Kommandos zum Ändern von Zielen
Mit den folgenden Kommandos arbeiten Sie mit den Ziel-Units:
| Aufgabe | systemd-Kommando | System V-init-Kommando |
| Aktuelles Ziel/Runlevel ändern | systemctl isolate MEIN_ZIEL.target | telinit X |
| Zum standardmäßigen Ziel/Runlevel wechseln | systemctl default | n/v |
| Aktuelles Ziel/Runlevel abrufen | systemctl list-units --type=target
Bei systemd sind in der Regel mehrere Ziele aktiv.
|
who -r
oder runlevel |
| Standard-Runlevel dauerhaft ändern | Verwenden Sie die Dienste-Verwaltung, oder führen Sie das folgende Kommando aus:
ln -sf /usr/lib/systemd/system/ MEIN_ZIEL.target /etc/systemd/system/default.target |
Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile
id: X:initdefault: in /etc/inittab |
| Standard-Runlevel für den aktuellen Bootprozess ändern | Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:
systemd.unit= MEIN_ZIEL.target |
Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein. |
| Abhängigkeiten für ein Ziel/Runlevel anzeigen | systemctl show -p "Requires" MEIN_ZIEL.target
systemctl show -p "Wants" 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 |
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 /var/log/ 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.
Prüfen des Startvorgangs der Dienste
Mit dem Kommando systemctl 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 systemctl status MEIN_DIENST erhalten Sie weitere Informationen zu einem bestimmten Dienst.
Liste der aktiven Dienste
# 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 = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e.
- generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
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 --failed an:
Liste der fehlerhaften Dienste
# 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
[...]
Fehlersuche für die Startzeit
Mit dem Kommando systemd-analyze 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.
Auflisten der Startzeit des Systems
# systemd-analyze Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
Auflisten der Startzeit der Dienste
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
Grafische Darstellung der Startzeit der Dienste
# systemd-analyze plot > jupiter.example.com-startup.svg
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 systemd 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
systemd schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer.
- Diesen Puffer zeigen Sie mit dmesg an:
$ dmesg -T | less
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 su oder sudo in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.
Wenn Sie den Benutzer mit su oder sudo ä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 .service:
[Unit] Description=DESCRIPTION After=network.target
[Service] User=USER Type=forking1 PIDFile=PATH TO PID FILE
ExecStart=PATH TO INIT SCRIPT start ExecStop=PATH TO INIT SCRIPT stop ExecStopPost=/usr/bin/rm -f PATH TO PID FILE
[Install] WantedBy=multi-user.target2
Ersetzen Sie alle Werte in GROSSBUCHSTABEN durch die entsprechenden Werte.
| 1 | Optional; nur zu verwenden, wenn mit dem init-Skript ein Daemon gestartet wird. |
| 2 | multi-user.target startet ebenfalls das init-Skript, wenn Sie in graphical.target booten.
|
- Starten Sie den Daemon mit systemctl start ANWENDUNG.