close
Zum Inhalt springen

systemd

aus Wikipedia, der freien Enzyklopädie
systemd
Image
Basisdaten
Hauptentwickler Lennart Poettering, Kay Sievers (Red Hat Inc.)
Entwickler Lennart Poettering[1], Kay Sievers[1], Harald Hoyer
Erscheinungsjahr 30. März 2010
Aktuelle Version 261.2[2]
(23. Juli 2026)
Betriebssystem Linux
Programmier­sprache C[3]
Kategorie Systemsoftware
Lizenz GNU LGPL 2.1+[4]
(Freie Software)
systemd.io
Image
systemd-Komponenten des Tizen-Betriebssystems für mobile Geräte

systemd ist eine Sammlung von Programmen, Hintergrundprogrammen (Daemons) und Bibliotheken für Linux-Betriebssysteme. Ihr zentraler Bestandteil ist der systemd init-Prozess, der als erster Prozess (Prozess-ID 1) zum Starten, Überwachen und Beenden weiterer Prozesse dient. Es bietet aber auch andere Systemkomponenten an, deren Bandbreite vom Booten („systemd-boot“) bis zum Logging („journald“) reichen. Systemd wurde von Lennart Poettering, Kay Sievers (Red Hat Inc.) und anderen in C[3] programmiert und wird als freie Software unter der GNU Lesser General Public License (LGPL) veröffentlicht.[4]

Der Name entspricht mit dem abschließenden „d“ dem für Daemons üblichen Namensschema: systemd ist der Daemon, der das System startet und betreut.

Geschichte

[Bearbeiten | Quelltext bearbeiten]

Die Ideen und Konzepte zu systemd entstanden aus der Betrachtung von bereits bestehenden modernisierten init-Systemen[5] wie launchd von macOS und SMF (Service Management Facility) von Solaris. Es wurde am 10. April 2010 veröffentlicht. Von 2011 bis 2015 sind die größten Distributionen auf systemd umgestiegen:

Die wichtigsten Distributionen, die systemd bewusst gar nicht oder nicht standardmäßig nutzen, sind:

Ab Version 221 enthält systemd sd-bus, eine unabhängige D-Bus-Programmierschnittstelle, die bei der Komplexität zwischen libdbus und GDBus angesiedelt ist. sd-bus unterstützt sowohl das klassische dbus1 im Userspace als auch kdbus als Backend und soll so den reibungslosen Übergang zur Interprozesskommunikation im Kernel ermöglichen.[12]

In Version 260 wurde die Abwärtskompatibilität zu SysVinit-Skripten entfernt.[13]

Technik

[Bearbeiten | Quelltext bearbeiten]

Da systemd bewusst Features benutzt, die nur unter Linux zur Verfügung stehen, nicht aber auf anderen unixoiden Betriebssystemen, kann es nur auf Systemen mit Linux-Kernel laufen.

Ziele

[Bearbeiten | Quelltext bearbeiten]

systemd soll in seiner Kernfunktion die gegenseitigen Abhängigkeiten von Prozessen und anderen Aspekten des Systemzustands organisieren. Dazu gehört insbesondere die verlässliche sowohl Steuerung der Systemkomponenten als auch Erkennung von deren Statusänderungen und das Auslösen von Reaktionen darauf. Ebenfalls von großer Bedeutung ist die leichte Nutzbarkeit auch komplizierter Konfigurationsmöglichkeiten (systemd hat inklusive der optionalen Systemdienste etwa 1.500 Konfigurationsdirektiven). Das flexiblere Abhängigkeitssystem kann zu stärkerer Parallelisierung beim Systemstart und somit einer kürzeren Bootzeit führen als das klassische SysVinit oder das überwiegend nur noch bei ChromeOS zum Einsatz kommende Upstart. Über die Steuerung der Systemkomponenten hinaus hat systemd einige Systemdienste neu implementiert, deren Nutzung mal mehr, mal weniger optional ist.

Units

[Bearbeiten | Quelltext bearbeiten]

systemd verwaltet nicht nur Dienste, sondern auch weitere wichtige Komponenten eines Linux-Systems. Diese Verwaltung erfolgt über so genannte Units, von denen es unterschiedliche Typen gibt und die als Textdateien konfiguriert werden, die an Windows-INI-Dateien angelehnt sind. Die Typen sind:

  • .mount: Einhängepunkt
  • .service: Daemonen, sowohl für das System als auch für die Benutzer
  • .device: Hardware (Sysfs-Einträge, udev)
  • .socket: Sockets (v. a. IP oder UNIX Domain Sockets)
  • .swap: Auslagerungsspeicher
  • .automount: Automounter (Einhängen von Dateisystemen erst bei Bedarf)
  • .path: Überwachung von Dateisystempfaden, überwiegend mittels inotify: Starten einer Unit, wenn die konfigurierte Veränderung eintritt.
  • .slice: hierarchische Zusammenfassung von Units zur Ressourcensteuerung (cgroups)
  • .scope: Zusammenfassung von Prozessen, die nicht von systemd erzeugt wurden, etwa der Prozessbaum eines SSH-Logins
  • .nspawn: systemd-Container (systemd-nspawn); Alternative zu LXC (Linux Containers)

Eine Sonderstellung haben die .timer- und .target-Units, die außerhalb von systemd nicht sichtbar sind:

  • .timer: Die systemd-Variante von Cronjobs. Wenn eine .timer-Unit ausgelöst wird, startet sie eine Unit.
  • .target: Gruppierung von Units für das gemeinsame Starten und Stoppen (systemctl isolate, nicht systemctl stop; analog zu Runleveln) und die (vereinfachte) Prüfung, ob alle benötigten Units aktiv sind.

Die Konfiguration fast aller Parameter über die Unit-Dateien ist nicht nur deutlich einfacher, weil komplexe Sachverhalte und Kommandoaufrufe zu häufig einer einzigen Zuweisung eingedampft werden, sondern spart auch Ressourcen, weil der Aufruf externer Kommandos aus einem Script durch wenige Systemaufrufe ersetzt werden.

Units müssen nicht zwingend in Unit-Dateien erstellt werden. Für etablierte Arten, Dinge zu konfigurieren, die in systemd als Unit abgebildet werden, gibt es systemd-Unit-Generatoren (die bei jedem Laden der systemd-Konfiguration laufen, also nur transiente Units erzeugen). Die wichtigsten sind:

  • systemd-fstab-generator: Erzeugt aus den /etc/fstab-Einträgen .mount-Units
  • systemd-cryptsetup-generator: Erzeugt instanziierte .service-Units zum Entschlüsseln von Blockgeräten, die in /etc/crypttab konfiguriert sind
  • Vor systemd 260 gab es einen Generator, der aus SysVinit-Scripten .service-Units erzeugte.

Drop-in-Dateien

[Bearbeiten | Quelltext bearbeiten]

Wenn man die von der Distribution oder dem Softwareanbieter bereitgestellte Unit ändern möchte, kann man diese ersetzen, was zu Konflikten bei Updates führen kann (wenn entweder die eigene Änderung überschrieben wird oder man wichtige Änderungen verpasst). Man kann stattdessen einzelne oder mehrere Direktiven in gesonderten Dateien setzen oder ändern. systemd fügt diese Dateien mit der Unit-Datei zusammen. Die Drop-In-Dateien für die Unit ssh.service befinden sich ggf. in ssh.service.d/*.conf. Dies kann man auch nutzen, um gemeinsame Konfigurationen aus einer Quelldatei in mehrere Units einzubinden (per Symlink).

Abhängigkeiten

[Bearbeiten | Quelltext bearbeiten]

Start-Stopp-Abhängigkeiten und Reihenfolge

[Bearbeiten | Quelltext bearbeiten]

Es gibt in systemd zwei Arten von Abhängigkeiten, die auf nicht offensichtliche Weise unabhängig voneinander sind und deshalb typischerweise (um eine Startvoraussetzung zu erreichen) kombiniert werden müssen:

  • Start-Stopp-Abhängigkeiten (v. a. Wants=, Requires=, BindsTo=, Conflicts=)
  • Reihenfolge-Abhängigkeiten (After=, Before=)

Der Start einer Unit kann das Starten oder Stoppen anderer Units auslösen. Das Booten (das eine .target-Unit hat) ist diesbezüglich nicht grundsätzlich verschieden vom späteren manuellen Starten einer einzelnen Unit:

  1. Es werden rekursiv die Abhängigkeiten zwischen allen involvierten Units erfasst.
  2. Für alle zu startenden Units werden Transaktionen mit Start-Jobs erstellt.
  3. Alle wartenden Start-Jobs, für die alle Startvoraussetzungen erfüllt sind, werden gleichzeitig gestartet. Wenn der Start einer Unit fehlschlägt, werden alle Start-Jobs, für die diese Unit eine Startvoraussetzung ist, abgebrochen.

Die Abhängigkeiten einer einzelnen Unit kann man sich mit systemctl list-dependencies anzeigen lassen. Eine grafische Gesamtansicht aller Abhängigkeiten im System kann man mit systemd-analyze dot erstellen.

Um den erfolgreichen Start der Unit srv.mount zu einer Startvoraussetzung für die Unit apache2.service zu machen, benötigt apache2.service zweierlei:

  • eine zwingende Start-Stopp-Abhängigkeit (Requires=, BindsTo=), also eine, deren Fehlschlagen nicht akzeptiert wird (anders als bei Wants=)
  • eine Reihenfolge-Abhängigkeit (After=, Before=)

Ohne die Reihenfolge-Abhängigkeit würden beide Units gleichzeitig gestartet und hätte das Fehlschlagen von srv.mount (innerhalb von systemd) keine Auswirkungen auf apache2.service (außer bei BindsTo=). Wenn nur die Reihenfolge-Abhängigkeit konfiguriert ist, wird srv.mount womöglich gar nicht gestartet (es sei denn, eine andere Unit löst dies aus). Wenn die Unit zufällig doch gestartet wird, wartet systemd mit dem Start von apache2.service, bis der Start von srv.mount geglückt oder fehlgeschlagen ist, und startet dann in jedem Fall apache2.service.

Startvoraussetzung und Reihenfolge von apache2.service
--keine Start-Stopp-AbhängigkeitWants=Requires=BindsTo=Conflicts=
keine Reihenfolge-Abhängigkeitsrv.mount läuft startet(1)startetstartetstartetstartet(2)
srv.mount scheitert startet(1)startetstartetstartet, aber wird nach dem Fehlschlagen von srv.mount beendetstartet(2)
After=srv.mount läuft startet(1) nach srv.mountstartet nach srv.mountstartet nach srv.mountstartet nach srv.mountstartet(2) nach dem Beenden von srv.mount
srv.mount scheitert startet(1) nach srv.mountstartet nach srv.mountstartet nichtstartet nichtstartet(2) nach dem Beenden von srv.mount
  • (1) aber srv.mount wird möglicherweise gar nicht gestartet
  • (2) und löst (ggf. vor dem eigenen Start) die Beendigung der anderen Unit aus

Bei einer Conflicts=-Beziehung ist egal, ob eine After=- oder Before=-Reihenfolge konfiguriert ist, weil Stopp-Jobs immer vor Start-Jobs ausgeführt werden. Nur wenn gar keine Reihenfolge konfiguriert ist, wartet systemd mit dem Start nicht, bis die andere Unit beendet wurde.

systemd erfasst und steuert also die Übergänge von einem Systemzustand (Gesamtheit der Zustände aller Units) zum nächsten, wogegen SysVinit nur die Start- und Stoppreihenfolge von Scripten organisiert und diese dann unabhängig von dabei auftretenden Fehlern ausführt.

Erkennung eines erfolgreichen Unit-Starts

[Bearbeiten | Quelltext bearbeiten]

Der erfolgreiche Start von .service-Units, dessen Zeitpunkt wichtig ist, weil ab dann die Startvoraussetzung für andere Units erfüllt sein kann (die man so früh wie möglich starten möchte), wird für die einzelnen Untertypen dieser Unit unterschiedlich erkannt. Die Varianten sind:

  • Type=oneshot: Die Unit ist erst aktiv, wenn sich der darin konfigurierte Prozess aktiv beendet hat; hier kontrolliert der Prozess also den Start abhängiger systemd-Units
  • Type=dbus: Die Unit ist aktiv, sobald der D-Bus-Name registriert ist.
  • Type=notify: Dies ist nur möglich, wenn die Anwendung an systemd angepasst ist. Sie meldet direkt an systemd, wann sie einsatzbereit ist.
  • alle anderen: Die Unit ist aktiv, sobald der konfigurierte Prozess gestartet wurde. Das hat die Nachteile,
    • dass der Prozess bei der Initialisierung abstürzen kann
    • dass bei Prozessen, die lange für ihre Initialisierung brauchen, später gestartete Units versuchen, auf diesen Dienst zuzugreifen, bevor er erreichbar ist

Beschleunigung durch Socket-Abhängigkeit

[Bearbeiten | Quelltext bearbeiten]

Für Dienste, die entsprechend an systemd angepasst sind, kann der Startvorgang beschleunigt werden, indem die .service-Unit um eine .socket-Unit ergänzt wird. Wenn dann die Startvoraussetzung für abhängende Units auf die .socket-Unit geändert wird (After= nur für die .socket-Unit, Requires= ebenso oder für beide), kann die abhängige Unit gestartet werden, sobald systemd den Socket eingerichtet hat. Spätestens wenn eine Verbindung zu dem Socket aufgebaut wird, übergibt systemd den Socket an den Dienst. Dies ähnelt der Inetd-Vorgehensweise. Die .service-Unit kann entweder gleichzeitig mit der .socket-Unit gestartet werden (was die spätere Latenz reduziert) oder erst dann, wenn eine Verbindung aufgebaut wird (wodurch der Prozess erst mal keine Ressourcen verbraucht und wichtigere Dienste früher oder schneller starten können).

Komponenten

[Bearbeiten | Quelltext bearbeiten]

Dienste

[Bearbeiten | Quelltext bearbeiten]

systemd besteht aus der oben beschriebenen init-Kernfunktion und einigen optionalen Komponenten. Einige davon werden allerdings auf quasi allen systemd-Systemen verwendet.

Grad der Verwendung der systemd-Komponenten (Dienste)
KomponenteBestandteile der Komponente
systemd-Kernfunktionen init / PID 1systemctl; Erzeugung und Konfiguration der Linux-Objekte, denen die Units entsprechen; Erfassung und Änderung von deren Zustand
fast überall genutzte Komponenten systemd-journaldjournalctl; Logging der Kernel- und systemd-Meldungen und der Ausgabe (stdout, stderr) von .service-Units
systemd-logindSitzungs- und Seat-Verwaltung (Hardwarezugriff); Herunterfahren und Ruhezustand via Hardware- oder Software-Auslöser
systemd-udevdudevadm (nicht systemd-spezifisch); udevd wurde ins systemd-Projekt übertragen; Units können über udev-Regeln gestartet werden
auch praktisch optionale Komponenten systemd-machinedmachinectl; Erfassung laufender VMs und Container; Integration in ps: ps -eo pid,machine,cmd
systemd-networkdnetworkctl; .link-, .netdev- und .network-Dateien
systemd-resolvedresolvectl; DNS mit Erweiterungen
systemd-timesyncdNTP-Client
systemd-homedhomectl; pam_systemd_home; Handhabung von portablen, potentiell verschlüsselten Homeverzeichnissen mit signierten User-Informationen
systemd-hostnamedhostnamectl; Änderung diverser Varianten des Hostnamens via D-Bus und Polkit
systemd-importdimportctl; Import, Export und Download von VM und Container-Images
systemd-localedlocalectl; Einstellungen der System-Locale und der Tastaturbelegung
systemd-nsresourcedtransiente Zuweisung eines UID-GID-Bereichs für einen User-Namensraum
systemd-oomdoomctl; Beenden entsprechend konfigurierter Units, wenn RAM knapp wird, um dem weniger flexiblem OOM-Killer des Kernels zuvorzukommen
systemd-portabledportablectl; Systemdienst zum Anhängen, Abhängen und Untersuchen von portablen Dienste-Abbildern
systemd-socket-proxydbidirektionaler Proxy zwischen lokalen Sockets und anderen (möglicherweise nichtlokalen) Sockets
systemd-timedatedtimedatectl; Konfiguration von Uhrzeit und Zeitzone
systemd-userdbduserdbctl; nss-systemd; flexiblere Bereitstellung von User- und Gruppendaten im JSON-Format aus mehreren Quellen, aber auch via nsswitch

Werkzeuge

[Bearbeiten | Quelltext bearbeiten]

Neben den systemd-Daemonen gibt es eine Vielzahl an systemd-Werkzeugen, teils für systemd(-Dienste) selber, teils als Alternative für Werkzeuge, die mit systemd nichts zu tun haben. Einige dieser Werkzeuge dienen der leichteren Einrichtung von Systemen von einem Image. Dafür kann systemd auch SMBIOS Type 11 vendor strings vom Hypervisor übernehmen.

systemd-Werkzeuge (keine Dienste)
KommandoFunktion
Werkzeuge für systemd systemd-analyzeu. a.: Auswertung des Bootvorgangs (Zeiten); Prüfung der Konsistenz der Abhängigkeiten
systemd-catWeiterleitung der Ausgabe eines Kommandos an das systemd-Journal
systemd-cglsAnzeige der cgroups: .slice-, .scope- und .service-Units mit den enthaltenen Prozessen
systemd-cgtopAnzeige der Ressourcen (RAM, CPU- und I/O-Last) für die einzelnen Units
systemd-credsVerwaltung von Service-Zugangsdaten
systemd-deltaAnzeige der Unit-Änderungen über Pfadhierarchien und Drop-In-Dateien
systemd-escape(Un)Escape für Pfade und Unit-Namen, v.a Bindestriche in Instanznamen: /dev/mapper/foo-bar → dev-mapper-foo\x2dbar
systemd-inhibitHandhabung von Anforderungen, das System neu zu starten, herunterzufahren oder in den Ruhezustand zu versetzen und der Hardware, die sie auslöst (z. B. Power-Knopf, Laptop zuklappen)
systemd-notifyÜbermittlung von Zustandsinformationen eines Dienstes an den Service-Manager, insbesondere zur Überführung einer .service-Unit in den Zustand aktiv.
systemd-nspawnStarten eines Containers
systemd-pathAnzeige der von systemd verwendeten Pfade
systemd-runAusführung von transienten Kommandos via systemd (mit quasi beliebigen Unit-Direktiven inklusive der Startzeit)
systemd-vmspawnStarten einer virtuellen Maschine
verbreitet genutzte Werkzeuge systemd-tmpfilesAnlegen, Metadatenanpassung und Löschung von Dateien und Verzeichnissen
systemd-sysusersAnlegen von Usern und Gruppen
systemd-modules-loadLaden von Kernelmodulen aus /etc/modules-load.d
systemd-sysctlSetzen der Laufzeit-Kernelkonfiguration aus /etc/sysctl.d
systemd-cryptsetupEinrichtung und Aufhebung verschlüsselter Blockgeräte
systemd-ask-passwordClient-Interface für TTY-Passwortabfragen
systemd-tty-ask-password-agentSystem-Interface für TTY-Passwortabfragen
systemd-ac-powerErkennung des Stromversorgungszustands
systemd-binfmtRegistrierung von Formaten ausführbarer Dateien (für transparente Ausführung via QEMU)
systemd-cryptenrollNutzung von Krypto-Hardware (TPM oder externe Hardware) für LUKS-Verschlüsselung
systemd-detect-virtErkennung virtualisierter Umgebungen
systemd-hwdbVerwaltung der Hardware-Datenbank
systemd-integritysetupEinrichtung von Blockgeräten mit dm-integrity-Integritätssicherung
systemd-veritysetupEinrichtung von Blockgeräten mit dm-verity-Integritätssicherung
Werkzeuge zur initialen Einrichtung eines Systems systemd-firstbootInitialisierung / Zurücksetzen diverser Systemparameter
systemd-growfsVergrößern eines Dateisystems
systemd-machine-id-setupGenerierung der ID in /etc/machine-id
systemd-makefsFormatierung
systemd-mkswapEinrichtung von Auslagerungsspeicher
systemd-repartPartitionierung
nicht allgemein genutzte Werkzeuge bootctlInstallation und Verwaltung von systemd-boot und EFI-Boot-Konfiguration
busctlAbfrage von D-Bus
kernel-installInstallation von Kernel-Images und initramfs-Dateien
run0sudo-Alternative mit polkit-Authentifizierung
systemd-bless-bootmarkiert den aktuellen Bootvorgang als erfolgreich
systemd-bootEFI-Bootmanager
systemd-bsodSystemstart-Notfallprotokollmeldungen im Vollbild darstellen
systemd-confext(de)aktiviert (insbesondere unveränderbare) Systemerweiterungsabbilder (/etc)
systemd-dissectHandhabung von Dateisystem-Betriebssystemabbildern, insbesondere DDIs
systemd-exportExport von Container-Abbildern
systemd-id128Erzeugt sd-id128-UUIDs oder zeigt die des Systems an
systemd-importImport von Container-Abbildern
systemd-import-fsimportiert einen Verzeichnisbaum in den Speicher von systemd-machined
systemd-keyutilAktionen auf privaten Schlüsseln und X.509-Zertifikaten
systemd-pullDownload von VM-/Container-Abbildern
systemd-sbsignerzeugt Signaturen für EFI Secure Boot
systemd-socket-activateTest-Socket-Aktivierung von Daemons
systemd-ssh-proxySSH-Verbindung über lokale Sockets (ohne IP)
systemd-stdio-bridgeProxy zwischen STDIN/STDOUT und D-Bus
systemd-storagetmlokale Blockgeräte als NVMe-TCP-Massenspeichergeräte offenlegen
systemd-sysext(de)aktiviert (insbesondere unveränderbare) Systemerweiterungsabbilder (/usr & /opt)
systemd-vpickAuswahl einer passenden Version aus versionierten .v/-Verzeichnissen
ukifyErzeugung von Unified Kernel Images (UKIs)
varlinkctlAbfrage von Varlink-Diensten

Kritik

[Bearbeiten | Quelltext bearbeiten]

Systemd polarisierte die Community in der Anfangszeit stark. Es kam zu Flame-Wars und Shitstorms seitens der Befürworter und Gegner, die zum Teil jedoch auch gegen die Person der Entwickler selbst, insbesondere Poettering und Sievers, gerichtet waren.[14][15] Die Diskussion, ob man in Debian weiter SysVinit verwenden oder auf systemd oder aber ein anderes Init-System umsteigen sollte, führte zu monatelangen Streitereien und schließlich zu einer Abstimmung („General Resolution“),[16][17][18] zahlreichen Rücktritten[19] und einem Fork[20] unter dem Namen Devuan, der gänzlich ohne systemd auskommt.

Der Hauptkritikpunkt an systemd liegt in seinem Anspruch, deutlich mehr verschiedene Aufgaben als das alte SysVinit erledigen zu wollen, was es recht kompliziert und fehleranfällig mache und überdies die Unix-Philosophie verletze (Ein Programm soll nur ein Problem lösen, dieses aber möglichst gut). Viele Entwickler äußerten die Sorge, systemd schränke durch zu starke Festlegungen der Systemumgebung Freiheit und Flexibilität ein.[21] Vielfach wurde bemängelt, dass systemd Log-Dateien im Binärformat und nicht als einfache Textdateien speichert. Ein weiterer Kritikpunkt besteht in der Entscheidung, systemd explizit nur für Linux zu entwickeln.[14] Wiederholt wurde kritisiert, die Entwickler würden dazu neigen, Programmierfehler zu ignorieren oder zu bestreiten.[22][23][24][25] Die Devuan-Entwickler äußerten die Befürchtung, Debian und die anderen Großdistributionen seien nun von Red Hat in einem „Vendor-Lock-in“ gefangen.[26]

Theodore Ts’o kritisierte die zu starke Ausrichtung auf die Gnome-Desktop-Umgebung; es bestehe die Gefahr, dass viele Systemkomponenten mit anderen Desktops nicht mehr funktionieren würden. Dies könne langfristig zur völligen Unbenutzbarkeit anderer Desktops führen, wenn es keine Alternative zu systemd mehr gebe. Die Devuan-Entwickler spekulierten darüber, dass es langfristig zu einer Übernahme von Debian durch das Gnome-Projekt kommen könne.[21] Linus Torvalds gab an, er habe keine feste Meinung zu systemd; einige Eigenschaften wie binäre Logs seien irrsinnig, aber das seien Detailfragen und keine grundsätzlichen Probleme. Die systemd-Entwickler hätten generell eine zu großzügige Haltung gegenüber Programmfehlern und Kompatibilitätsproblemen.[22][23] InfoWorld berichtete, systemd-Entwickler hätten Programmierfehler ignoriert und Bugreports geschlossen, ohne die Fehler zu beheben, was dazu geführt habe, dass Torvalds mit Kay Sievers einen der führenden systemd-Entwickler von der Kernel-Entwicklung ausgeschlossen habe. In der Gesamtschau sei durch systemd eine Spaltung der Linux-Community eingetreten, die Linux langfristig schaden werde.[24][25] Mark Shuttleworth bezeichnete systemd im Oktober 2013 als „höchst invasiv und kaum gerechtfertigt“,[27] um dann doch nur wenige Monate später als „freundlicher Verlierer“ die Unterstützung Ubuntus für systemd bekanntzugeben.[28] Ende Oktober 2015 berichtete Slashdot, BusyBox-Entwickler Denys Vlasenko habe die systemd-Unterstützung aus BusyBox entfernt. Vlasenko erklärte, die für systemd Verantwortlichen seien unfreundlich zum Rest der Welt, somit gebe es für den Rest der Welt keinen Anlass, mit ihnen zu kooperieren.[29][30] Linus Torvalds äußerte im Juli 2017 auf der Linux-Kernel-Mailingliste „LKML.org“, er könne nicht mehr darauf vertrauen, dass „init“ das Richtige tue.[31][32][33]

Einbindung von Google-Diensten in den Code

[Bearbeiten | Quelltext bearbeiten]

Im September 2014 wurde bekannt, dass eine Komponente des systemd in bestimmten Fällen DNS-Anfragen an die Google-Nameserver weiterleitet, ohne dass der Administrator dies eingestellt hat, was zu Diskussionen um die Vertraulichkeit, Sicherheit und Integrität von Nutzerdaten führte. Der zuständige Debian-Maintainer wies die Kritik zurück.[34] Dieser Sachverhalt wurde im Juli 2015 erneut festgestellt.[35] Poettering verteidigte diese Einstellung mit der Begründung, er wolle ein funktionsfähiges System sicherstellen.[36]

Ebenfalls im Juli 2015 wurde auf GitHub moniert, dass Google-Zeitserver als default bzw. fallback fest in den Code des systemd eingebunden sind.[37] Auch diese Entscheidung wurde von Poettering verteidigt, obwohl er einräumte, dass die Google-Server ungenaue Daten lieferten.[38][39][40] Ein Google-Entwickler kritisierte diese Einstellung.[41][42]

Sicherheitslücken

[Bearbeiten | Quelltext bearbeiten]

Im September 2016 wurde ein Bug bekannt, der jedem unprivilegierten Benutzer eine DoS-Attacke auf systemd und die damit verbundenen Prozesse ermöglicht.[43] Der Musl-Entwickler Rich Felker sagte dazu, systemd sei ein großer monolithischer Prozess, der bei einem Fehler nicht teilweise ausfalle, sondern das ganze System zum Absturz bringe. Der entdeckte Bug sei weniger ein ernstes Sicherheitsproblem, sondern zeige vielmehr einen grundlegenden Designfehler auf.[44]

Anfang 2017 entwickelte sich eine Diskussion darüber, dass systemd Daemons mit Root-Rechten ausführt, wenn in der Konfiguration des Daemons ein mit einer Ziffer beginnender Benutzername angegeben ist. Die Sicherheitslücke wurde unterschiedlich bewertet. Seitens der Entwickler wurde erklärt, es handele sich um keinen Programmierfehler, denn derartige Benutzernamen seien auf Linux-Systemen unzulässig und es läge in der Verantwortung des Administrators, sie nicht zuzulassen. Darüber hinaus müsse ein Angreifer auf dem betroffenen System bereits Root-Rechte besitzen, um derartige Benutzernamen anlegen zu können. Der Bugreport wurde zunächst geschlossen.[45][46] Später wurde ein Patch eingebaut, der bewirkt, dass fehlerhafte Parameter bei sicherheitskritischen Optionen nicht mehr ignoriert werden, sondern dazu führen, dass der Prozess nicht geladen wird.[31][47]

Im Juni 2017 wurde eine seit 2015 bestehende Verwundbarkeit in systemd-resolved entdeckt. Diese erlaubt es, systemd durch einen kompromittierten DNS-Server zur Ausführung von Schadprogrammen zu veranlassen, wodurch der Dienst zum Absturz gebracht oder durch externe Angreifer übernommen werden könne. Über die Sicherheitslücke wurde zuerst von Canonical-Mitarbeiter Chris Coulson berichtet.[48] Demnach sind seit 2015 die Versionsnummern 223 bis 233 betroffen. Red Hat teilte mit, das von ihnen vertriebene Red Hat Enterprise Linux 7 sei nicht verwundbar. Debian erklärte, das kürzlich erschienene Debian 9 (Codename „Stretch“) sei ebenfalls nicht betroffen, da systemd-resolved standardmäßig nicht aktiviert sei. Ein Patch schloss die Sicherheitslücke in den betroffenen Versionen.[49][50][51]

Im Oktober 2018 wurde bekannt, dass ein Programmierfehler im IPv6-DHCP-Client von systemd dazu missbraucht werden kann, verwundbare Linux-Systeme mit manipulierten DHCP-Paketen zu übernehmen.[52]

Das US-amerikanische IT-Sicherheitsunternehmen Qualys berichtete im Januar 2019 über einen Fehler in der systemd-Komponente journald, der es Benutzern erlaube, auf einem System root-Rechte zu erlangen. Dies gelang auf einem x86-System innerhalb von zehn, auf einem amd64-System innerhalb von 70 Minuten.[53]

Literatur

[Bearbeiten | Quelltext bearbeiten]
  • Thorsten Leemhuis: Sammelstelle – Log-Informationen beim Journal von Systemd abrufen. c’t 13/2014, Seite 168
  • Yogesh Babar: Hands-on Booting. Apress, 2020. ISBN 978-1-4842-5889-7. Kapitel 7 und 9.
[Bearbeiten | Quelltext bearbeiten]
Commons: Systemd – Sammlung von Bildern und Videos

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. 1 2 README - systemd/systemd - System and Session Manager. (englisch, abgerufen am 17. November 2018).
  2. ↑ Release 261.2. 23. Juli 2026 (abgerufen am 24. Juli 2026).
  3. 1 2 systemd. In: Analysis Summary. Ohloh, archiviert vom Original (nicht mehr online verfügbar) am 15. Oktober 2012; abgerufen am 15. August 2011.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
  4. 1 2 Lennart Poettering: License. In: systemd git. freedesktop.org, abgerufen am 3. Februar 2013.
  5. ↑ Interview mit Lennart Poettering, Entwickler Systemd. golem.de, 27. Mai 2011, abgerufen am 18. März 2013.
  6. ↑ Lennart Poettering: The Biggest Myths. Abgerufen am 3. Februar 2013 (englisch).
  7. ↑ Release Notes: SUSE Linux Enterprise Server 12 Release Notes. Abgerufen am 2. März 2015.
  8. ↑ Release Notes for Oracle Linux 7. Abgerufen am 15. August 2026 (englisch).
  9. ↑ Release Notes: Ubuntu 15.04 Release Notes. Abgerufen am 23. April 2015.
  10. ↑ Debian 8 „Jessie“ veröffentlicht. 25. April 2015, abgerufen am 26. April 2015.
  11. ↑ Linux Mint 18. Abgerufen am 15. August 2026.
  12. ↑ The new sd-bus API of systemd, 19. Juni 2015
  13. ↑ Michael Larabel: systemd 260 Released: mstack, SysV Service Scripts Removed & AI Agents Documentation. In: Phoronix. 17. März 2026, abgerufen am 20. März 2026 (englisch): „System V service scripts are no longer supported and now you must be relying on native systemd unit files.“
  14. 1 2 Ferdinand Thommes: Systemd als Schaltzentrale für das Linux-System. In: LinuxUser, Ausgabe 04/2014. Abgerufen am 26. Februar 2016.
  15. ↑ Ferdinand Thommes: Linus Torvalds kritisiert Systemd-Entwickler scharf. In: ComputerBase. 3. April 2014, abgerufen am 24. August 2016.
  16. ↑ Thorsten Leemhuis: Debian-Abstimmung zum Init-System: Keine Grundsatzentscheidung erforderlich. In: Heise online. 19. November 2014, abgerufen am 26. Februar 2016.
  17. ↑ Thorsten Leemhuis: Debian entscheidet sich für Systemd – zumindest fürs Erste. In: Heise online. 11. Februar 2014, abgerufen am 26. Februar 2016.
  18. ↑ Thorsten Leemhuis: Debian: Wahl zum Standard-Init-System führt zu Zank. In: Heise online. 2. November 2014, abgerufen am 26. Februar 2016.
  19. ↑ Oliver Diedrich: Debian: Systemd-Streit vertreibt Entwickler. In: Heise online. 17. November 2014, abgerufen am 26. Februar 2016.
  20. ↑ Oliver Diedrich: Devuan: Jetzt solls los gehen. In: Heise online. 13. Januar 2015, abgerufen am 26. Februar 2016.
  21. 1 2 Joe Casad: Debian Gets Forked; Legendary Uber-distro splits over the systemd controversy. In: Linux Magazine. 2. Dezember 2014, abgerufen am 11. September 2017 (englisch).
  22. 1 2 Kristian Kißling: Linus Torvalds stört sich nicht an Systemd. In: Linux-Magazin. 18. September 2014, abgerufen am 24. August 2016.
  23. 1 2 Steven Vaughan-Nichols: Linus Torvalds and others on Linux’s systemd. In: ZDNet. 14. September 2014, abgerufen am 24. August 2016 (englisch).
  24. 1 2 Paul Venezia: Systemd: Harbinger of the Linux apocalypse. In: InfoWorld. International Data Group, 18. August 2014, abgerufen am 26. August 2016 (englisch).
  25. 1 2 Silviu Stahie: Linus Torvalds Blocks All Code from Systemd Developer for the Linux Kernel. In: Softpedia. 3. April 2014, abgerufen am 26. August 2016 (englisch).
  26. ↑ Ferdinand Thommes: Devuan veröffentlicht erste Beta ohne Systemd. In: ComputerBase. 29. April 2016, abgerufen am 22. Dezember 2016.
  27. ↑ Mark Shuttleworth: Quantal, raring, saucy… In: Homepage von Mark Shuttleworth. 18. Oktober 2013, abgerufen am 13. Juli 2017 (englisch).
  28. ↑ Mark Shuttleworth: Losing Graciously. In: Homepage von Mark Shuttleworth. 14. Februar 2014, archiviert vom Original (nicht mehr online verfügbar) am 8. September 2014; abgerufen am 14. Oktober 2021 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
  29. ↑ Denys Vlasenko: remove systemd support. 22. Oktober 2015, abgerufen am 7. November 2016 (englisch).
  30. ↑ Busybox Deletes Systemd Support. Slashdot, 31. Oktober 2015, abgerufen am 7. November 2016 (englisch).
  31. 1 2 Jürgen Schmidt: Systemd-Entwickler wollen die „0day“-Lücke nun doch schließen. In: Heise online. 11. Juli 2017, abgerufen am 13. Juli 2017.
  32. ↑ Linus Torvalds: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec. In: LKML.org. 6. Juli 2017, abgerufen am 13. Juli 2017 (englisch).
  33. ↑ Simon Sharwood: Linus Torvalds may have damned systemd with faint praise. The Register, 17. Juli 2017, abgerufen am 24. Juli 2017 (englisch).
  34. ↑ Debian Bug report logs - #761658; Please do not default to using Google nameservers. Abgerufen am 23. August 2016 (englisch).
  35. ↑ Source der Datei systemd/configure.ac. In: Github. Archiviert vom Original (nicht mehr online verfügbar) am 24. August 2016; abgerufen am 24. August 2016.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
  36. ↑ FallbackDNS shouldn’t have values set at compile time #494. In: Github issue #494. Abgerufen am 24. August 2016 (englisch).
  37. ↑ Source der Datei systemd/configure.ac. In: Github. Archiviert vom Original (nicht mehr online verfügbar) am 24. August 2016; abgerufen am 24. August 2016 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
  38. ↑ timeX.google.com provide non standard time #437. In: Github issue #437. Abgerufen am 24. August 2016 (englisch).
  39. ↑ timesyncd: default NTP pool instead of Google NTP #439. In: Github issue #439. Abgerufen am 24. August 2016 (englisch).
  40. ↑ Do not provide default NTP servers. Fixes #437. #444. In: Github issue #444. Abgerufen am 24. August 2016 (englisch).
  41. ↑ Systemd soll Googles Zeitserver nicht mehr verwenden. In: golem.de. 1. Juli 2015, abgerufen am 24. August 2016.
  42. ↑ Kristian Kißling: Keine Zeit für Systemd? In: Linux-Magazin. 1. Juli 2015, abgerufen am 24. August 2016.
  43. ↑ Assertion failure when PID 1 receives a zero-length message over notify socket #4234. In: Github issue #4234. Abgerufen am 5. Oktober 2016 (englisch).
  44. ↑ Tom Spring: Hack Crashes Linux Distros with 48 Characters of Code. In: Threatpost. Kaspersky Lab, 3. Oktober 2016, abgerufen am 6. Oktober 2016 (englisch).
  45. ↑ Sebastian Krahmer: Headsup: systemd v228 local root exploit (CVE-2016-10156). In: LWN.net. 24. Januar 2017, abgerufen am 13. Juli 2017 (englisch).
  46. ↑ Jürgen Schmidt: Aufregung über angebliche Sicherheitslücke in systemd. In: Heise online. 3. Juli 2017, abgerufen am 13. Juli 2017.
  47. ↑ Refuse to load some units by keszybz · Pull Request #6300 · systemd/systemd. In: github.com. GitHub, abgerufen am 13. Juli 2017 (englisch).
  48. ↑ Chris Coulson (Canonical): CVE-2017-9445: Out-of-bounds write in systemd-resolved with crafted TCP payload. Openwall, 27. Juni 2017, abgerufen am 13. Juli 2017 (englisch).
  49. ↑ USN-3341-1: Systemd vulnerability. In: Canonical (Ubuntu). 27. Juni 2017, abgerufen am 13. Juli 2017 (englisch).
  50. ↑ Shaun Nichols: Don’t panic, but Linux’s Systemd can be pwned via an evil DNS query. The Register, 29. Juni 2017, abgerufen am 13. Juli 2017 (englisch).
  51. ↑ Liam Tung: Linux’s systemd vulnerable to DNS server attack. In: ZDNet. 29. Juni 2017, abgerufen am 13. Juli 2017 (englisch).
  52. ↑ heise Security: Systemd: DHCPv6-Pakete können Linux-Rechner kapern. Abgerufen am 30. Oktober 2018.
  53. ↑ Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet. In: Slashdot. 10. Januar 2019, abgerufen am 22. Januar 2019 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Systemd&oldid=269742904“