# Systemd

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 programmiert und wird als freie Software unter der GNU Lesser General Public License (LGPL) veröffentlicht.
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

Die Ideen und Konzepte zu systemd entstanden aus der Betrachtung von bereits bestehenden modernisierten init-Systemen wie launchd von macOS und SMF (Service Management Facility) von Solaris. Es wurde am 10. April 2010 veröffentlicht. Distributionen, die systemd als vorgegebenen init-Dienst verwenden, sind Fedora ab Version 15, openSUSE ab Version 12.1, Mandriva 2011, Mageia ab Version 2, Arch Linux seit Oktober 2012, Red Hat Enterprise Linux ab Version 7, Tizen sowie siduction ab Version 2013.2, SUSE Linux Enterprise Server ab Version 12, Ubuntu ab Version 15.04 und Debian ab Version 8.
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.

## Technik

Systemd ist abwärtskompatibel zu SysVinit-Skripten. Allerdings werden bewusst Features benutzt, die nur unter Linux zur Verfügung stehen, nicht aber auf anderen unixoiden Betriebssystemen. Es kann daher nur auf Systemen mit Linux-Kernel laufen.
Es soll den gegenseitigen Abhängigkeiten von Prozessen besser gerecht werden, durch mehr Parallelisierung zu einer besseren Auslastung beim Systemstart führen und somit weniger Verzögerungen verursachen als das ältere, klassische SysVinit oder das kaum noch in klassischen Linux-Distributionen, sondern nur noch überwiegend bei ChromeOS zum Einsatz kommende Upstart.
Grundlegendes Konzept dafür ist es, weitgehend alle Prozesse gleichzeitig zu starten. Um nicht, wie bei anderen zwar grundsätzlich auf Parallelisierung setzenden Systemen, anhand der in einem Modell erfassten wechselseitigen Abhängigkeiten der Prozesse teilweise noch mit Serialisierung zu arbeiten, werden die D-Bus-Verbindungen und Sockets zur Interprozesskommunikation schon vor dem Start des zugehörigen Dienstes bereitgestellt und vom Kernel eventuell auflaufende Nachrichten bis zur Bereitschaft des Dienstes gepuffert. Ähnliches wird für Anfragen an Dateisysteme mittels autofs bewerkstelligt.
Daneben kann es nur gelegentlich benötigte Dienste ereignisbasiert erst bei Bedarf starten und so beim Systemstart weniger Dienste starten. Damit nimmt es Aufgaben wahr, die bei klassischen Unix-Systemen von inetd übernommen werden.
Weiterhin sollen alle Shell-Boot-Skripte durch deklarative Konfigurationsdateien ersetzt werden, in denen definiert wird, wie die jeweiligen Dienste gestartet werden. Diese Dateien sind in der Regel deutlich einfacher zu schreiben als init-Skripte und vermeiden den erheblichen Overhead von Shell-Skripten.

## Kritik

Systemd polarisiert die Community äußerst stark. Dadurch kommt es 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 sind. 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“), zahlreichen Rücktritten und einem Fork unter dem Namen Devuan, wobei Devuan 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. 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. Wiederholt wurde kritisiert, die Entwickler würden dazu neigen, Programmierfehler zu ignorieren oder zu bestreiten. 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.
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. 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. 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. Mark Shuttleworth bezeichnete systemd im Oktober 2013 als „höchst invasiv und kaum gerechtfertigt“, um dann doch nur wenige Monate später als „freundlicher Verlierer“ die Unterstützung Ubuntus für systemd bekanntzugeben. 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. 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.

### Einbindung von Google-Diensten in den Code

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. Dieser Sachverhalt wurde im Juli 2015 erneut festgestellt. Poettering verteidigte diese Einstellung mit der Begründung, er wolle ein funktionsfähiges System sicherstellen.
Ebenfalls im Juli 2015 wurde auf GitHub moniert, dass Google-Zeitserver als default bzw. fallback fest in den Code des systemd eingebunden sind. Auch diese Entscheidung wurde von Poettering verteidigt, obwohl er einräumte, dass die Google-Server ungenaue Daten lieferten. Ein Google-Entwickler kritisierte diese Einstellung.

### Sicherheitslücken

Im September 2016 wurde ein Bug bekannt, der jedem unprivilegierten Benutzer eine DoS-Attacke auf systemd und die damit verbundenen Prozesse ermöglicht. 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.
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. 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.
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. 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.
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.
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.