Systemd Grundlagen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 1: Zeile 1:
*[[Systemd Grundlagen]]
+
 
 
= Besonderheiten =
 
= Besonderheiten =
 
; Abwärtskompatibilität zu SysVinit-Scripten
 
; Abwärtskompatibilität zu SysVinit-Scripten

Version vom 18. September 2022, 11:56 Uhr

Besonderheiten

Abwärtskompatibilität zu SysVinit-Scripten
systemd ist abwärtskompatibel, jedoch werden Features benutzt, welche nur unter Linux verfügbar sind.
Somit ist er nur auf Systemen mit Linux-Kernel lauffähig.
Parallelisierung
Es werden möglichst viele Prozesse gleichzeitig beim Booten gestartet um das System optimal aus zulasten.
Abhängigkeits-Regeln
Um bei der Parallelisierung dennoch sicher zustellen dass Dienste welche von anderen Diensten benötigt werden rechtzeitig vor diesen zu starten. (z.B. D-Bus)
cgroups
Anstelle von ProzessIDs werden cgroups benutzt. Dies bedeutet, dass Dienste nicht mehr "Abhauen" können. Selbst durch doppeltes Forken.
Ereignis basiertes Starten von Diensten
Ähnlich inetd kann systemd Dienste bei Bedarf starten.
Dies kann z.B. über einen Socket oder Bus geschehen.
Binärscripte
Langfristig sollen Shell-Skripte komplett verschwinden und anstelle eines Init-Skripts jeder Dienst eine Konfigurationsdatei erhalten in welcher definiert wird wie dieser zu starten ist.
Kommandos
Bei Sys-V-init laufen Dienste immer im Hintergrund als Daemon. Bei Systemd wird erwartet, dass der Prozess hinter exec im Vordergrund läuft. Nur so lange der Prozess im Vordergrund durchgeführt wird betrachtet Systemd ihn auch als laufend. Endet der mit exec gestarter Prozess, so endet für Systemd auch der Service und dieses wartet nun darauf, dass wieder ein passendes Traget auftritt.
Prozesse beenden
Beim Stoppen eines Jobs kümmert sich Systemd ausschließlich um den per exec im Vordergrund gestarteten Prozess. Er sendet ein SIGTERM und erwartet, dass er sich selbst beendet. Falls er dies jedoch nicht tut wird er mittels SIGKILL einfach abgebrochen.

Verfügbarkeit (01/2015)

Distribution Status
Fedora Fedora seit version 15 Standard
openSUSE openSUSE seit 12.1 Standard
Mandriva seit Mandriva 2011 Standart
Debian seit debian 8 jessie Standart
Ubuntu seit 15.04
Arch seit Oktoper 2012
Red Hat seit version 7

systemd wurde als externe Abhängigkeit für GNOME 3.2 vorgeschlagen.

Units

Systemd wird über Dateien mit einem INI-Datei ähnlichen Format konfiguriert. In der Terminologie von systemd sind dies "Units". Bei Ubuntu vorinstallierte Units sind im Ordner /lib/systemd/system/ gespeichert. Falls sich jedoch eine Unit mit gleichem Namen im Verzeichnis /etc/systemd/system/ befindet, so wird diese bevorzugt und jene unterhalb von /lib ignoriert. Damit hat man die Möglichkeit, eine Unit an eigene Gegebenheiten anzupassen, ohne dass man befürchten muss, dass sie bei einer Systemaktualisierung überschrieben wird. Es existieren verschiedene Typen von Units, die von systemd je nach Endung des Dateinamens unterschiedlich behandelt werden:


Typ Beschreibung
.device Legt Gerätedateien an
.mount Ein- und Aushängen von Dateisystemen
.path Startet die Unit via inotify
.service Für Dienste
.socket Stellt Verbindungen zwischen Prozessen her
.target Definiert eine Gruppe von Units
.timer Für wiederkehrende Aufgaben, ähnlich cron-Jobs

Befehl zum Anzeigen

  • systemctl list-units (zum anzeigen aller Units auf einem System)


  • systemctl list-units --type service (zum anzeigen aller Units vom Typ "Service" auf einem System)
apport.service            loaded active     exited        LSB: automatic crash r
apt-daily.service         loaded activating start   start Daily apt activities
atd.service               loaded active     running       Deferred execution sch
...

Administration

Runlevel / Targets

SystemVinit Runlevel Systemd Target Kommentar
0 runlevel0.target, poweroff.target System herunterfahren
1, s, single runlevel1.target, rescue.target Einzelnuzer Modus
2, 4 runlevel2.target, runlevel4.target, multi-user.target Benuzerdefiniert, Standardmäsig identisch zu 3
3 runlevel3.target, multi-user.target Multi-user, Shell. Anmeldung über mehrere Consolen und7oder netzwerk
5 runlevel5.target, graphical.target Multi-user, Grafisch. Gewöhnlich alle Dienste aus 3 sowie grafische Oberfläche
6 runlevel6.target, reboot.target Reboot
emergency emergency.target Notfall Shell

systemctl

Service File

Änderungen

Nach Änderungen

  • systemctl daemon-reload
  • systemctl enable firewall.service
  • systemctl start firewall.service

journalctl

systemd verwendet standardmäßig ein zentrales Protokoll bzw. Journal, in das von journald alle Logmeldungen geschrieben werden. Zur Abfrage des Journals dient der Befehl journalctl.

Bootlogs

  • journalctl -b

Journal vom 1 September bis zum 2. September 3 Uhr

  • journalctl --since "2016-09-01" --until "2016-09-02 03:00"


FAQ

Wie setze ich das Runlevel beim Booten?
Unter systemd werden Runlevel als Targets bezeichnet. Um das Boot "Target" beim Booten zu setzen hängt man z.B. einen der folgenden Kernel Parameter an.
  • systemd.unit=multi-user.target (entspricht Runlevel 3)
  • systemd.unit=rescue.target (entspricht Runlevel 1)


Wie setze ich das Standard Target?
Für Runlevel 3
# systemctl -f enable multi-user.target
Für Runlevel 5
# systemctl -f enable graphical.target