Systemd ist eine Programm-paket, die eine Reihe von Systemkomponenten für Linux-Betriebssysteme bereitstellt. Die Hauptkomponente ist ein “System- und Service-Manager” - ein Init-System, das zum Booten des User-Space und zur Verwaltung von Benutzerprozessen verwendet wird.
Zu den weiteren Funktionen gehören der parallele Start von Diensten, die Socket- und D-Bus-Aktivierung zum Starten von Diensten, das bedarfsorientierte Starten von Daemons, die Verfolgung von Prozessen mit Hilfe von Linux-Control-Groups, die Verwaltung von Mount- und Automount-Punkten und die Implementierung einer ausgefeilten transaktionalen, abhängigkeitsbasierten Dienststeuerungslogik.
Zu den weiteren Teilen gehören ein Logging-Daemon, Dienstprogramme zur Steuerung der grundlegenden Systemkonfiguration wie Hostname, Datum, Gebietsschema, die Aufrechterhaltung einer Liste von angemeldeten Benutzern und laufenden Containern und virtuellen Maschinen, Systemkonten, Laufzeitverzeichnisse und -einstellungen sowie Daemons zur Verwaltung der einfachen Netzwerkkonfiguration, Netzwerk-Zeitsynchronisation, Log-Weiterleitung und Namensauflösung.
Das Programm /sbin/init (auch als init
bezeichnet) koordiniert den Rest des Bootvorgangs und konfiguriert die
Umgebung für den Benutzer. Wenn der init-Befehl startet,
wird er zum Eltern- oder Großelternprozess aller Prozesse, die
automatisch im System starten. Heutzutage ist
sbin/initunter Debian (und alle seine Derivate) ein
Symlink, welcher zu /lib/systemd/system verweist. Der Grund
für den Erhalt von sbin/init ist die Kompatibilität mit
alten Programmen.
Systemd verwendet Einheiten (units), um Systemressourcen und Dienste zu verwalten. Eine Unit ist eine Konfigurationsdatei, die beschreibt, wie ein spezifischer Systemdienst, eine Systemressource oder ein Gerät zu behandeln ist. Es gibt verschiedene Typen von Units, die jeweils unterschiedliche Aspekte des Systems kontrollieren.
.service)Diese Units definieren Systemdienste. Ein Beispiel für eine Service-Unit-Konfigurationsdatei:
[Unit]
Description=My Example Service
After=network.target
[Service]
ExecStart=/usr/bin/my-service
Restart=always
[Install]
WantedBy=multi-user.target.socket)Diese Units beschreiben Sockets, die von Systemd überwacht werden. Wenn eine Verbindung an einem dieser Sockets eingeht, kann ein zugehöriger Dienst gestartet werden.
[Unit]
Description=My Example Socket
[Socket]
ListenStream=1234
[Install]
WantedBy=sockets.target.target)Diese Units dienen dazu, Gruppen von Units zu organisieren und systemweite Zustände zu erreichen.
[Unit]
Description=My Example Target.mount)Diese Units beschreiben Mount-Punkte im Dateisystem.
[Unit]
Description=Mount Example
[Mount]
What=/dev/sdb1
Where=/mnt/example
Type=ext4
[Install]
WantedBy=multi-user.target.automount)Diese Units beschreiben Automount-Punkte, die das automatische Einhängen von Dateisystemen ermöglichen.
[Unit]
Description=Automount Example
[Automount]
Where=/mnt/example
[Install]
WantedBy=multi-user.target.timer)Diese Units konfigurieren zeitgesteuerte Aufgaben ähnlich wie Cron-Jobs.
[Unit]
Description=Run Example Service Daily
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target.path)Diese Units überwachen Dateisystempfade und können bei Änderungen Aktionen auslösen.
[Unit]
Description=Monitor Example Path
[Path]
PathModified=/path/to/monitor
[Install]
WantedBy=multi-user.target.slice)Diese Units organisieren und steuern Gruppen von Prozessen.
[Unit]
Description=Example Slice.scope)Diese Units verwalten Prozesse, die nicht von systemd gestartet wurden.
Eine Unit-Datei besteht aus mehreren Abschnitten, von denen die wichtigsten hier erläutert werden.
Dieser Abschnitt enthält generische Informationen über die Unit, wie die Beschreibung und Abhängigkeiten.
[Unit]
Description=My Example Unit
After=network.targetDiese Abschnitte enthalten spezifische Einstellungen für den jeweiligen Unit-Typ. Ein Service-Abschnitt könnte beispielsweise den Befehl definieren, der beim Start des Dienstes ausgeführt wird.
[Service]
ExecStart=/usr/bin/my-service
Restart=alwaysDieser Abschnitt definiert, wie und wann die Unit installiert und aktiviert wird.
[Install]
WantedBy=multi-user.targetsystemctl ist das zentrale Werkzeug zur Verwaltung von
Systemd-Diensten. Es bietet eine Vielzahl von Befehlen und Optionen, um
Dienste zu steuern, den Status zu überprüfen und Systemeinstellungen zu
verwalten.
Überprüft den Status eines Dienstes.
systemctl status <dienstname>-l, --full: Zeigt vollständige Ausgaben an.-n <zeilen>, --lines=<zeilen>: Begrenze die
Anzahl der Journalzeilen.--no-pager: Deaktiviert die Ausgabe im Pager.Listet alle aktiven Einheiten (units) auf.
systemctl list-units--type=<type>: Filtert nach Einheitstypen (z.B.
service, socket, device).--all: Zeigt auch inaktive Einheiten.--state=<state>: Filtert nach Einheitenstatus
(z.B. active, inactive,
failed).Aktiviert einen Dienst so, dass er beim Systemstart automatisch gestartet wird.
systemctl enable <dienstname>--now: Aktiviert und startet den Dienst sofort.--force: Erzwingt die Aktivierung, auch wenn sie
problematisch sein könnte.Deaktiviert einen Dienst, so dass er beim Systemstart nicht automatisch gestartet wird.
systemctl disable <dienstname>--now: Deaktiviert und stoppt den Dienst sofort.Startet einen Dienst sofort.
systemctl start <dienstname>Stoppt einen laufenden Dienst sofort.
systemctl stop <dienstname>Stoppt und startet einen Dienst neu.
systemctl restart <dienstname>Lädt die Konfiguration eines laufenden Dienstes neu, ohne ihn neu zu starten.
systemctl reload <dienstname>Zeigt die Konfigurationsdateien einer Einheit an.
systemctl cat <dienstname>Überprüft, ob ein Dienst aktiviert ist.
systemctl is-enabled <dienstname>Überprüft, ob ein Dienst aktiv ist.
systemctl is-active <dienstname>Systemd-analyze kann verwendet werden, um Leistungsstatistiken beim Systemstart zu ermitteln und andere Zustands- und Tracing-Informationen vom System- und Servicemanager abzurufen sowie die Korrektheit von Unit-Dateien zu überprüfen. Es wird auch verwendet, um auf spezielle Funktionen zuzugreifen, die für fortgeschrittene Systemmanager-Debugging-Zwecke nützlich sind.
Dieser Befehl gibt die Zeit aus, die im Kernel verbracht wurde, bevor der Benutzerbereich erreicht wurde, die Zeit, die im initrd verbracht wurde, bevor der normale Systembenutzerbereich erreicht wurde, und die Zeit, die der normale Systembenutzerbereich benötigt hat, um initialisiert zu werden.
# in a container
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# on a real machine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspaceZeigt eine Liste aller laufenden Programme und Dienste an, sortiert nach der Zeit, die sie brauchten, um sich zu starten. Das kann helfen, langsame Programme zu finden und den Startvorgang zu beschleunigen. Beachte jedoch, dass die Zeit, die ein Programm braucht, auch davon abhängen kann, dass es auf ein anderes Programm wartet. Außerdem zeigt der Befehl keine Ergebnisse für sehr einfache Programme an. Er zeigt auch nicht an, wie lange Programme auf andere Programme warten müssen.
$ systemd-analyze blame
32.875s pmlogger.service
20.905s systemd-networkd-wait-online.service
13.299s dev-vda1.device
...
23ms sysroot.mount
11ms initrd-udevadm-cleanup-db.service
3ms sys-kernel-config.mountZeigt eine Liste von Einheiten und deren Startzeiten an, die für den erfolgreichen Start anderer Einheiten wichtig sind. Es zeigt, wie lange eine Einheit braucht, um zu starten, und ob sie auf eine andere Einheit wartet. Die Ausgabe kann jedoch nicht alle Arten von Wartezeiten genau erfassen und ist möglicherweise nicht vollständig.
$ systemd-analyze critical-chain
multi-user.target @47.820s
└─pmie.service @35.968s +548ms
└─pmcd.service @33.715s +2.247s
└─network-online.target @33.712s
└─systemd-networkd-wait-online.service @12.804s +20.905s
└─systemd-networkd.service @11.109s +1.690s
└─systemd-udevd.service @9.201s +1.904s
└─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
└─kmod-static-nodes.service @6.976s +177ms
└─systemd-journald.socket
└─system.slice
└─-.sliceWenn du diesen Befehl ohne Zusatz verwendest, zeigt er dir eine lange Liste aller laufenden Programme und Dienste auf deinem Computer. Du kannst auch Muster angeben, um die Liste auf bestimmte Programme zu beschränken. Die Ausgabe ist für normale Anwendungen nicht immer leicht zu verstehen und kann sich ändern. Und nicht-Admin-Benutzer können diesen Befehl nur begrenzt verwenden.
$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
Description: /proc/timer_list
...
-> Unit default.target:
Description: Main user targetDieser Befehl gibt entweder eine SVG-Grafik aus, die detailliert darstellt, welche Systemdienste zu welcher Zeit gestartet wurden und wie lange sie für die Initialisierung benötigt haben, oder die Rohzeitdaten im JSON- oder Tabellenformat.
$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&Dieser Befehl erstellt eine Beschreibung der Abhängigkeiten zwischen den verschiedenen Diensten auf deinem System im dot-Format. Diese Beschreibung kann dann mit dem GraphViz-Tool dot verwendet werden, um einen grafischen Abhängigkeitsbaum zu erstellen. Wenn du beispielsweise systemd-analyze dot | dot -Tsvg >systemd.svg eingibst, wird eine SVG-Datei mit dem Baum erstellt. Du kannst auch Muster angeben, um nur bestimmte Einheiten oder Dienste in den Baum aufzunehmen.
$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg
$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
| dot -Tsvg >targets.svg
$ eog targets.svgDieser Befehl zeigt eine Liste von Linux-Fähigkeiten zusammen mit ihren Zahlenwerten an. Wenn keine Argumente angegeben sind, werden alle Fähigkeiten aufgelistet, die dem Servicemanager und dem Kernel bekannt sind. Fähigkeiten, die nur vom Kernel definiert sind, werden als “cap_???” angezeigt. Wenn du spezifische Fähigkeiten anzeigen möchtest, kannst du ihre Namen oder Zahlenwerte als Argumente verwenden.
$ systemd-analyze capability 0 1 {30..32}
NAME NUMBER
cap_chown 0
cap_dac_override 1
cap_audit_control 30
cap_setfcap 31
cap_mac_override 32Dieser Befehl analysiert und normalisiert wiederkehrende Kalenderzeitereignisse und berechnet, wann sie als nächstes eintreten werden. Dabei verwendet er dieselbe Eingabe wie die OnCalendar= Einstellung in systemd.timer(5), wobei die Syntax in systemd.time(7) beschrieben wird. Standardmäßig wird nur der nächste Zeitpunkt angezeigt, an dem der Kalenderausdruck eintritt. Mit –iterations= kannst du die angegebene Anzahl der nächsten Zeitpunkte anzeigen lassen, an denen der Ausdruck eintritt. Jedes Mal, wenn der Ausdruck eintritt, bildet sich ein Zeitstempel, siehe das Verb “timestamp” weiter unten.
$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
Next elapse: Sat 2020-02-29 00:00:00 UTC
From now: 11 months 15 days left
Iter. #2: Thu 2024-02-29 00:00:00 UTC
From now: 4 years 11 months left
Iter. #3: Tue 2028-02-29 00:00:00 UTC
From now: 8 years 11 months left
Iter. #4: Sun 2032-02-29 00:00:00 UTC
From now: 12 years 11 months left
Iter. #5: Fri 2036-02-29 00:00:00 UTC
From now: 16 years 11 months leftDieser Befehl analysiert einen Zeitstempel (d. h. einen einzelnen Zeitpunkt) und gibt die normalisierte Form sowie die Differenz zwischen diesem Zeitstempel und der aktuellen Zeit aus. Der Zeitstempel sollte der Syntax entsprechen, die in systemd.time(7), Abschnitt “PARSING TIMESTAMPS” dokumentiert ist.
$ systemd-analyze timestamp yesterday now tomorrow
Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
(in UTC): Sun 2019-05-19 22:00:00 UTC
UNIX seconds: @15583032000
From now: 1 day 9h ago
Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
(in UTC): Tue 2019-05-21 07:48:39 UTC
UNIX seconds: @1558424919.659757
From now: 43us ago
Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
(in UTC): Tue 2019-05-21 22:00:00 UTC
UNIX seconds: @15584760000
From now: 14h leftDieser Befehl ähnelt “systemctl cat”, funktioniert jedoch auf Konfigurationsdateien. Er kopiert den Inhalt einer Konfigurationsdatei und eventueller Drop-Ins in die Standardausgabe, unter Verwendung des üblichen systemd-Verzeichnis- und Prioritätsregelsatzes. Jedes Argument muss entweder ein absoluter Pfad einschließlich des Präfix sein (wie /etc/systemd/logind.conf oder /usr/lib/systemd/logind.conf) oder ein Name relativ zum Präfix (wie systemd/logind.conf).
$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
... some override from another package
# /etc/systemd/logind.conf.d/50-override.conf
... some administrator overrideDieser Befehl lädt Einheitsdateien und gibt Warnungen aus, wenn Fehler gefunden werden. Er lädt die Dateien, die du auf der Befehlszeile angegeben hast, sowie alle anderen Einheiten, auf die sie verweisen. Du kannst auch einem Einheitsnamen auf der Festplatte einen Alias zuweisen. Der Suchpfad für Einheiten wird durch die Verzeichnisse der Befehlszeilenargumente und die üblichen Suchpfade gebildet. Du kannst auch die Variable $SYSTEMD_UNIT_PATH verwenden, um den Suchpfad anzupassen. Einheiten in Verzeichnissen, die in den Befehlszeilenargumenten angegeben sind, haben Vorrang vor anderen Pfaden.
Die folgenden Fehler werden derzeit erkannt:
Unbekannte Abschnitte und Anweisungen, - Fehlende Abhängigkeiten, - die erforderlich sind, um die angegebene Einheit zu starten, - Man-Pages, - die in “Documentation=” aufgeführt sind, - aber nicht im System gefunden werden, - Befehle, - die in “ExecStart=” und ähnlichen Feldern aufgeführt sind, - aber nicht im System gefunden werden oder nicht ausführbar sind.
Beispiel: Einheit umbenennen
$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
Failed to prepare filename /tmp/source: Invalid argument
$ systemd-analyze verify /tmp/source:alias.service
alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.Dieser Befehl überprüft die Sicherheitseinstellungen von einem oder mehreren spezifizierten Diensten. Wenn du einen Dienstnamen angibst, zeigt er detaillierte Informationen zu dessen Sicherheitseinstellungen an. Ohne Angabe eines Dienstnamens überprüft er alle laufenden Dienste und zeigt eine kurze Tabelle mit den Ergebnissen an. Er bewertet die Sicherheitsstufe jedes Dienstes basierend darauf, wie gut er gegen potenzielle Angriffe geschützt ist. Eine hohe Sicherheitsstufe bedeutet eine geringere Anfälligkeit für Angriffe, während eine niedrige Sicherheitsstufe auf mögliche Schwachstellen hinweist. Beachte jedoch, dass diese Analyse nur die Sicherheitseinstellungen berücksichtigt, die von systemd selbst umgesetzt werden. Es werden keine zusätzlichen Sicherheitsmaßnahmen berücksichtigt, die möglicherweise vom Dienst selbst implementiert wurden.
$ systemd-analyze security --no-pager systemd-logind.service
NAME DESCRIPTION EXPOSURE
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ User=/DynamicUser= Service runs as root user 0.4
✗ DeviceAllow= Service has no device ACL 0.2
✓ IPAddressDeny= Service blocks all IP address ranges
...
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂
Dieser Befehl lädt die angegebenen Dateien. Falls es sich bei diesen Dateien um ELF-Objekte handelt (das sind beispielsweise ausführbare Dateien, Bibliotheken oder Kerneldateien), wird der in den Dateien eingebettete Verpackungsmetadaten analysiert. Wenn solche Metadaten vorhanden sind, werden sie in einer Tabelle oder im JSON-Format ausgegeben.
$ systemd-analyze inspect-elf --json=pretty \
core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
{
"elfType" : "coredump",
"elfArchitecture" : "AMD x86-64",
"/home/bluca/git/fsverity-utils/fsverity" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
},
"/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
}
}Dieser Befehl analysiert den angegebenen Image-Richtliniensatz gemäß systemd.image-policy(7). Die Richtlinie wird normalisiert und vereinfacht. Für jeden aktuell definierten Partitionskennzeichner (gemäß der Spezifikation für entdeckbare Partitionen) wird die Wirkung des Image-Richtliniensatzes in tabellarischer Form angezeigt.
PARTITION MODE READ-ONLY GROWFS
root encrypted - -
usr verity yes -
home ignore - -
srv ignore - -
esp ignore - -
xbootldr ignore - -
swap encrypted - -
root-verity ignore - -
usr-verity unprotected yes -
root-verity-sig ignore - -
usr-verity-sig ignore - -
tmp ignore - -
var ignore - -
default ignore - -