Systemd polarisiert die Community – und hat zugleich das Zeug dazu, alte Gräben zu schließen und eine einheitliche Basis für Linux zu bilden.
Systemd ist das Ergebnis der Arbeit einer Vielzahl von Entwicklern. Geht es aber um das Gesicht, dass die Software in der Öffentlichkeit repräsentiert, führt kaum ein Weg an Lennart Poettering vorbei. Der streitbare Entwickler hat auf seiner To-do-Liste bereits einige wichtige Projekte abgehakt, darunter Avahi und das Soundsystem Pulseaudio. Mit Systemd arbeitet er nun seit 2010 daran, zentrale Dienste auf eine moderne, einheitliche Basis zu stellen – ausgehend von einem neuen Ansatz für das Init-System.
Dabei schreckt Poettering vor unbequemen Entscheidungen nicht zurück, was ihm den Ruf eintrug, diktatorische Methoden einzusetzen. Die Entscheidung, Systemd nur für Linux zu entwickeln, brachte ihm zusätzlich Kritik, Häme und Beschimpfungen ein. Für ihn hat die Entscheidung aber klar nachvollziehbare Gründe.
Poettering tritt neben seiner Arbeit an Systemd für eine Vereinheitlichung des Linux-Desktops über Distributionen hinweg ein. Sein neuestes Projekt, das er unter anderem mit Kernel-Guru Greg Kroah-Hartman verfolgt, befasst sich damit, das Nachrichtensystem Dbus als Kdbus im Kernel zu integrieren. Auf seine Ankündigung bei Google Plus [1], dass Systemd zusammen mit Kdbus und allen Userspace-Tools in Fedora einwandfrei startet und somit ein weiterer Meilenstein erreicht sei, hagelte es allerdings wieder postwendend harsche Kritik.
Solche Anfeindungen haben den Red-Hat-Entwickler aber noch nie vom Kurs abgebracht (siehe Kasten “Lennart Poettering im Interview”). Er trägt gern das Herz auf der Zunge (Abbildung 1) und ist ein Freidenker mit genug Rückgrat und Rückhalt, um seine Visionen durchzusetzen und ein paar alte Linux-Zöpfe abzuschneiden.
Abbildung 1: Mit einem T-Shirt zeigte Lennart Poettering auf der FOSDEM 2014, was er von den Aussprüchen von Mark Shuttleworth hält.
Lennart Poettering im Interview
LU: Was glaubst Du, warum Systemd so kritisch betrachtet wird, obwohl es konsequenter umgesetzt ist, als so manch andere Software, die wir täglich benutzen?
LP: Systemd wird zwar kontrovers diskutiert, aber insgesamt fällt das Urteil inzwischen klar häufiger positiv als negativ aus. Die jüngste Entscheidung von Debian für Systemd macht deutlich, dass nicht nur einzelne Distributionen sich für den Ansatz entscheiden, sondern die klare Mehrheit aller größeren Distributionen.
Freilich gibt es eine beträchtliche Minderheit in der Community, die Systemd kritisiert oder gleich ganz ablehnt. Die Gründe dafür fallen vielfältig aus. Eine große Rolle spielt sicherlich, dass das Konzept schlicht alte Zöpfe abschneidet und eine große Veränderung zum klassischen Unix-System darstellt.
Eine weitere Ursache liegt wohl in der Tatsache, dass Systemd nicht nur den eigentlichen Boot-Prozess optimiert, sondern gleich einen großen Teil der Low-Level-Komponenten des Systems vereinheitlicht.
Wieder andere in der Community lehnen das Ganze aus wirtschaftlichen Gesichtspunkten ab. So hat etwa Canonical viel Aufwand in die Entwicklung von Upstart gesteckt und war daher verständlicherweise sehr interessiert, dem eigenen Projekt zum Erfolg zu verhelfen.
LU: Debian hat sich nach viel Zank um Befindlichkeiten für Systemd entschieden. Siehst Du die letzten Monate als demokratischen Prozess oder einfach als den Beweis für das Fehlen eines wohlmeinenden Diktators?
LP: Die verschiedenen Distributionen organisieren sich unterschiedlich: Debian setzt auf einen demokratischen Prozess, Ubuntu dagegen auf das Konzept eines “wohlmeinenden Diktators”. Fedora versucht etwas in der Mitte dazwischen, eine Art Technokratie.
Sicherlich waren die Debatten zu diesem Thema in Debian häufig unerfreulich. Aber nach all den chaotischen Diskussionen bleibt nur, festzustellen, dass genau dies den demokratischen Prozess ausmacht und dass das demokratische System durchaus funktioniert.
Der Vorgang gestaltet sich langwierig, und manchmal macht es sicherlich keinen Spaß, aber das ist der Deal: Will man ein universelles Betriebssystem schaffen, bedeutet das, dass man besonders viele Leute einbeziehen muss, was zwangsläufig für umfangreichere Diskussionen und eine größere Bandbreite der Beiträge sorgt – im Positiven wie im Negativen.
LU: Systemd soll weiter ins Userland vordringen, und du möchtest Prozesse in den Desktop-Umgebungen mit den gleichen Mechanismen starten wie das System selbst. Kocht Systemd bald sogar den Kaffee?
LP: Was genau zu den Aufgaben von Systemd gehört und was nicht, darüber lässt sich trefflich streiten. Es gibt noch einige Module, die wir noch integrieren. Generell gilt: Infrage kommen Komponenten des sogenannten Plumbing Layers – also weder Kernel und noch Oberfläche, sondern mehr die “Klebe” dazwischen.
Für uns zählt immer die allgemeine Verwendbarkeit, wir wollen also eine generische Lösung, nie eine spezifische. Systemd ist damit niemals ein Produkt, sondern nur etwas, woraus andere Entwickler Produkte bauen. Es sollte im besten Fall dazu dienen, das System zusammenzuhalten, aber mit dem Nutzer nie in Kontakt treten.
Um auf den Kaffee zurückzukommen: Nach dieser Definition ist Systemd sicherlich eine brauchbare Komponente, neben vielen anderen, um eine internetfähige Kaffeemaschine zu bauen – es kocht aber selbst nie den Kaffee. Das wäre viel zu speziell und nicht mehr die “Klebe”, welche die Kaffeemaschine zusammenhält. Ich selbst bevorzuge ohnehin Club Mate als Koffeinquelle. Daher liegt mir nichts ferner, als Kaffeemaschinen-Funktionen in Systemd einzubauen.
LU: Nicht nur deine Software, sondern auch deine Person ist in der Szene umstritten. Du gehst damit recht lässig um. Verstehst du, warum so viele auch dich persönlich kritisieren, und trifft Dich das?
LP: Wer versucht, eine zentrale Komponente des Linux-Ökosystems auszutauschen, erntet damit natürlich viel Kritik, das war unvermeidlich. Die Community hat nun einmal starke Überzeugungen, und wer widerspricht, gerät leicht zum Buhmann.
Systemd war nicht das erste Projekt, das versucht hat, das Boot-System von Linux umzukrempeln – es gab bereits Dutzende. Wir haben uns schon häufig selbst gefragt, warum es uns gelungen ist, unseren Ansatz durchzusetzen. Wir würden uns wünschen, dass das vor allem an technischen Gründen liegt. Zumindest in unseren Augen stellt Systemd definitiv das bessere System dar.
Eine große Rolle spielt aber sicher auch, wie wir mit dem Druck aus der Community umzugehen gelernt haben. Meinen Mitstreitern und mir ist wohl besser als den meisten anderen gelungen, unseren Humor zu behalten und klare Überzeugungen zu entwickeln, und das mit langem Atem.
Die Linux-Community führt sich manchmal grässlich auf. Will man etwas Zentrales durchsetzen, dann darf man nicht zu zart besaitet sein. Es wäre sicherlich schön, wenn das nicht so wäre!
Zu den Wurzeln
Wer sich mit dem Init-System beschäftigt, erkennt sehr schnell, warum die Arbeit an dieser zentralen Komponente so viel Wirbel erzeugt. Der Begriff kommt von “Initiieren” und umfasst bei Unix-ähnlichen Betriebssystemen den Start des Systems, aber auch das geordnete Herunterfahren.
Init ist der erste Prozess, den der Kernel erzeugt, und er startet alle anderen als Kindprozesse. Er erhält deshalb die Prozess-ID 1 (PID 1). Zu den Aufgaben von Init zählt im wesentlichen das Starten aller nötigen Dienste sowie das Einhängen der Dateisysteme und das Einrichten des Netzwerks.
Das bei Linux und anderen Unix-Abkömmlingen seit den 90er-Jahren genutzte Init-System Sysvinit [2] stammt aus dem Jahr 1988, als das amerikanische Unternehmen AT&T für sein Betriebssystem System V in Version R4 einen Startmechanismus brauchte.
Im Jahr 2004 ersetzte Solaris Sysvinit durch den Nachfolger Service Management Facility (SMF) [3], Mac OS X folgte 2005 mit Launchd [4]. Canonical nutzt seit 2007 das im eigenen Haus auf der Basis von Sysvinit-Code entwickelte Upstart [5]. Bei Gentoos FreeBSD-Ableger kommt seit 2007 als Alternative OpenRC [6] zum Einsatz.
Aus der Not geboren
Systemd stammt in der Hauptsache aus der Feder der beiden bei Red Hat angestellten Entwickler Lennart Poettering und Kai Sievers. Bevor die beiden ab 2007 darangingen, das Init-System unter Linux zu renovieren, schauten sie sich sowohl bei Launchd als auch bei SMF genauer um, da diese Init-Systeme im Gegensatz zum statischen Sysvinit die Möglichkeit bieten, Prozesse parallel zu starten.
Da auch Upstart diese Fähigkeit besitzt, war die ursprüngliche Idee der Entwickler, Ubuntus Init-System zu erweitern. Juristische Gründe, die mit Canonicals Contributor License Agreement (CLA) [7] zu tun haben, verhinderten das Vorhaben, da weder Poettering noch Sievers bereit waren, diese Vereinbarung zu unterzeichnen.
Somit wurde Systemd aus der Not geboren. Zwei grundsätzliche Entscheidungen von damals erregen bis heute die Gemüter: Systemd wurde bewusst kompromisslos nur auf Linux ausgelegt. Systeme mit anderen Kerneln wie BSD oder Hurd bleiben erst einmal außen vor; eine Portierung nach BSD ist zwar möglich, aber aufwendig.
Darüber hinaus kratzt Systemd am alten Unix-Prinzip “one tool for one job”, indem es einige der Jobs ziemlich eng miteinander verzahnt. In Zukunft mag sich das etwas lockern, sodass Funktionen einzeln zur Nutzung bereitstehen, wie das Ubuntu jetzt bereits bei Upstart in Verbindung mit Logind tut.
Mehr als Init
Systemd steht als Abkürzung für System-Daemonen, also im Hintergrund ablaufende Prozesse, die dem System Dienste zur Verfügung stellen. Der Init-Prozess stand am Anfang der Entwicklung und erhält auch die meiste Aufmerksamkeit. Es gibt jedoch weitere Komponenten wie etwa Logind oder das Journal, die Systemd ebenso ausmachen.
Der Init-Prozess von Systemd basiert auf einem schlanken PID-1-Dienst, der nur das Nötigste erledigt. Dank parallelisiertem Ausführen läuft das Hoch- und Herunterfahren des Computers mit Systemd wesentlich flotter ab. Es basiert auf einer Technik, die Apple für Launchd entwickelt hat: Socket Activation.
Socket Activation ermöglicht es, fast alle Dienste parallel zu starten. Der Prozess vereinfacht sich außerdem, da Entwickler und Administratoren nicht mehr darauf achten müssen, welcher Dienst an welcher Stelle beim Booten mit welchen Abhängigkeiten startet.
Der Trick besteht darin, dass Systemd die Sockets zur Kommunikation mit den zu startenden Diensten selbst anlegt und die bereits früh anfallenden Daten puffert, bis der eigentliche Dienst läuft und sie annimmt. Das Konzept von Sysvinit dagegen zwingt abhängige Dienste dazu, aufeinander zu warten, da das Init-System selbst keine Daten speichert.
Dass fast alle Dienste gleichzeitig starten, trägt bei Systemd wesentlich dazu bei, die Struktur der Service-Files zu vereinfachen. Diese lösen die schwer oft wild gewachsenen Shell-Skripte von Sysvinit ab. Die Abbildungen 2 und**3 zeigen die Unterschiede am Beispiel von Kexec [8] auf.
Abbildung 2: Sysvinit: Das Startskript von Kexec weist an zahlreichen Stellen Konstrukte auf, deren Zweck nicht auf den ersten Blick ersichtlich ist.
Abbildung 3: Systemd: Das Service-File von Kexec benötigt nur wenige Zeilen, deren Funktion sich weitgehend durch die Namen der Variablen erschließt.
Systemd organisiert alle beim Start anstehenden Aufgaben – wie das Bereitstellen der Hardware, Einhängen der Dateisysteme und Starten der Dienste – in Units. Die Service-Files der verschiedenen Units hören auf jeweils eigene Suffixe, die ihrerseits einen Hinweis auf die Tätigkeit geben.
Dateien mit der Endung .mount kümmern sich dabei um das Ein- und Aushängen von Dateisystemen, solche mit der Endung .service bedienen die Dienste, die im Hintergrund laufen. Diese Units lagern einheitlich unter /lib/systemd/system. Für eine Modifikation kopieren Sie die fragliche Datei von Hand nach /etc/systemd/system/ und editieren sie nach Bedarf; das System nutzt fortan automatisch diese.
Eine wichtige Entscheidung beim Design von Systemd, die dazu betrug, dass Systemd bislang nur unter Linux zum Einsatz kommt, war die Integration von Cgroups [9]. Solche Control Groups erlauben, Kernel-Ressourcen zuzuteilen und zu limitieren, wie etwa CPU-Zeit, Datendurchsatz oder Arbeitsspeicher für Prozessgruppen.
Systemd bringt ab Version 205 dafür neue Unit-Typen mit. Dazu zählen Scope- und Slice-Units. Mit Ersteren fassen Sie Systemdienste oder Anwendungen samt ihrer Abhängigkeiten in Cgroups zusammen und verwalten sie. Die Slice-Units versorgen die Units mit benötigten Ressourcen.
Langfristig möchten die Entwickler den Einsatz und die Kontrolle der Cgroups völlig an den Daemon übergeben. Damit würde Systemd endgültig zu einer neuen Zwischenschicht zwischen Kernel und Anwendungen. Poettering selbst sieht ihn als “Klebstoff”, die Struktur fällt in jedem Fall sehr komplex aus (Abbildung 4).
Abbildung 4: Die verschiedenen Ebenen der Systemd-Infrastruktur machen es schwer, von einem einfachen Dienst zu sprechen.
Journal
Anders als Sysvinit protokolliert Systemd die Boot-Meldungen von Anfang an. Damit gehören die per Smartphone aufgenommenen Screenshots des Boot-Prozesses in Support-Foren endgültig der Vergangenheit an. Systemd erstellt dafür zur Laufzeit einen Socket [10], auf dem ein minimaler Log-Dienst läuft und die Meldungen der frühen Bootphase mitschreibt. Später übergibt er den Socket an den regulären Protokolldienst, und die Meldungen stehen im Journal bereit.
Das Journal löst das seit Langem verwendete Syslog ab. Bei einer ersten Demonstration hagelte es Kritik, weil es vom bisherigen Konzept des Speicherns in Textdateien mit flachen Hierarchien abweicht. Stattdessen legt der Dienst die Daten in einem binären Format ab.
Davon abgesehen hat das Journal einige schwer zu ignorierende Vorteile: Neben dem oben erwähnten Protokollieren des gesamten Boot-Vorgangs erlaubt es sehr gezielte Abfragen. So zeigt der Befehl aus der ersten Zeile von Listing 1 die Meldungen seit dem letzten Hochfahren des Systems, während das Kommando aus der zweiten Zeile aufführt, was der Webserver seit Mitternacht an Meldungen ausgegeben hat. In einem Blog-Eintrag zeigt Poettering wesentlich detailliertere Anfragen [11].
Listing 1
$ journalctl -b $ journalctl -u httpd --since=00:00 --until=9:30
Wie der Name Logind [12] schon andeutet, kümmert sich der Daemon um User- und Session-Management und löst voraussichtlich das nicht mehr fortgeführte ConsoleKit [13] ab. Damit begibt sich Systemd vom Kernel in den Userspace, was wiederum nicht ohne Kritik blieb.
Im Endeffekt will Poettering aber noch weitergehen, indem er auch die Prozesse zum Starten von Gnome oder KDE und deren Anwendungen mit dem gleichen Mechanismus versieht. Apples Mac OS X macht dies bereits vor. Erste Ansätze dazu lassen sich bereits in Gnome 3 erkennen, das seit Kurzem durch das Einbinden von Logind Teile von Systemd nach sich zieht.
Unendliche Geschichte
Distributionen wie Fedora und OpenSuse, aber auch Debian-Derivate wie Siduction, Semplice und demnächst Tanglu haben den Umstieg auf Systemd bereits vollzogen (Abbildung 5).
Abbildung 5: Mittlerweile existieren schon Frontends, um die Aktivitäten von Systemd im Auge zu behalten.
Die Abhängigkeiten zu Teilen von Systemd waren der Auslöser zur schwierigen Entscheidungsfindung über das künftige Init-System in Debian. Die Diskussion begann im Oktober 2013 mit einer Nachricht auf der Mailing-Liste der Debian-Entwickler [14]: Sie formulierte eine Beschwerde über die Abhängigkeit des Gnome-Settings-Daemon zu Systemd – eingeleitet durch die Hoffnung, keinen Flamewar auszulösen.
Doch genau das passierte: Die Diskussion verlief hitzig und ohne Ergebnis, bis nach rund einer Woche klar war, dass auf diesem Weg keine Lösung möglich war. Ein anderer Entwickler beantragte, das Technische Komitee (CTTE) [15] solle sich des Problems annehmen [16] und eine Entscheidung treffen [17].
Das CTTE machte sich mit den technischen Grundlagen vertraut und versuchte, eine von allen Mitgliedern getragene Lösung zu finden. Das Gremium umfasst acht Mitglieder – von denen sich ziemlich bald vier pro Systemd äußerten, die vier anderen pro Upstart. Von Letzteren sind zwei derzeit bei Canonical beschäftigt, bei einem Dritten handelt es sich um einen früheren Mitarbeiter der Ubuntu-Firma.
Das Debian-Projekt hat durch die vielen unterstützten Architekturen besondere Probleme. So war von Beginn an klar, dass die Plattformen Hurd und KFreeBSD nicht mit Systemd funktionieren. Das erwies sich für die größte Distribution, die ohne Unternehmen im Hintergrund ihre Entscheidungen trifft, sowohl als ein technisches als auch ein politisches Problem.
Von den drei Kandidaten, die Sysvinit ablösen könnten, gab es nur einen, mit dem das technische Problem zu beheben wäre: Neben Systemd und Upstart ging das bei Gentoo entwickelte OpenRC an den Start. Es hat zwar derzeit keine Chance, sich als Standard-Init-System zu etablieren, aber mit etwas Aufwand ließen sich damit durchaus beide Architekturen bedienen.
Im Fall von Upstart stünde ein Fork der Software an, da Canonical nur dann eine Mitarbeit erlaubt, wenn die Beteiligten das bereits erwähnte Contributor License Agreement (CLA) unterzeichnen (siehe Kasten “Canonicals Knebel”). Mark Shuttleworth hätte sich vermutlich die Hände gerieben, wenn Debian die Weiterentwicklung von Upstart übernimmt.
Canonicals Knebel
Das kontroverse Canonical-CLA definiert die Möglichkeit, Software unter eine Doppellizenz zu stellen. Dabei behält zwar der Entwickler sein Copyright, gibt Canonical aber das Recht, den Code einer anderen Lizenz zu unterstellen und Weiterentwicklungen nicht mehr unter der ursprünglichen Lizenz weiterzugeben.
Am Fall Systemd hat sich bei Debian die Diskussion um Canonical im Allgemeinen und CLAs im Besonderen wieder entfacht. Zu dieser Problematik äußerten sich nicht nur Kai Sievers und Lennart Poettering, sondern auch Linus Torvalds [18], Greg Kroah-Hartman [19] und Matthew Garrett [20] ausführlich.
Während Garrett nicht alle CLAs für schlecht hält – schließlich benutzt etwa die Apache Foundation eines – widersprach Torvalds und hält diese Verträge für fundamental falsch. Systemd-Mitentwickler Sievers brachte seine pragmatische Sicht der Dinge sarkastisch auf den Punkt: “Ohne CLA würden wir immer noch an Upstart arbeiten, statt sinnvolle Sachen an Systemd zu erledigen.”
Anfang Februar fand der zweite Satz an Fragen [21], die das Komitee-Mitglied Ian Jackson (einer der Canonical-Mitarbeiter) formuliert hatte, ebenfalls keine Zustimmung bei allen Mitgliedern, sodass ein dritter Fragenkatalog folgte. Dieser glich dem ersten, einfach gehaltenen Vorschlag – mit einem Unterschied: Er enthielt eine Klausel, die es den Debian-Entwicklern erlaubt, das ultimative Entscheidungswerkzeug bei Debian einzuberufen, die General Resolution (GR), und mit einfacher Mehrheit den Beschluss des CTTE aufzuheben [22].
Normalerweise erfordert eine solche Entscheidung bei Debian eine Zweidrittelmehrheit. Zur Einberufung einer GR benötigt es sechs offizielle Debian-Entwickler, die sich in der Sache einig sind. Mitte Februar kam es dann im dritten Wahlgang nach fast vier Monaten Diskussion zur Entscheidung. Der Vorsitzende Bdale Garbee löste eine Patt-Situation auf, indem er erstmals von seinem Sonderstimmrecht für solche Situationen Gebrauch machte und Systemd zum Sieger erklärte [23].
Ob die Entwickler die Entscheidung noch mit einer GR kippen, bleibt abzuwarten. Vermutlich würde auch dort Systemd gewinnen, hätte aber dann eine breitere Basis. Damit wäre den Kritikern das Argument einer willkürlichen Entscheidung aus der Hand genommen, Upstart hätte in dem Prozess kaum Chancen.
Das Prozedere zeigte aber auch, dass die Statuten des CTTE eventuell einer Reform bedürfen: Schwerlich waren die Versuche des einen oder anderen Mitglieds zu übersehen, das Verfahren zu verschleppen und zu torpedieren.
Canonical-Gründer Mark Shuttleworth gab sich wenige Tage nach der Entscheidung bei Debian in seinem Blog als “würdevoller Verlierer” und kündigte an, dass auch Ubuntu auf lange Sicht auf Systemd umschwenkt, sobald dieses von den Entwicklern als genauso stabil wie die bisherige Lösung Upstart deklariert sei.
Damit nehmen mit Debian und Ubuntu die letzten großen Distributionen Kurs auf Systemd. Zusammen haben sie eine kritische Masse, um Einfluss auf die Entwicklung im Sinne von Debian zu nehmen. Zudem verpufft künftig vielleicht weniger Energie zwischen den Distributionslagern: Slackware und Gentoo bleiben als einzige außen vor – Gentoo setzt weiter auf OpenRC, während Slackware vermutlich Sysvinit die Treue hält.
Boot-Prozess optimieren mit Systemd
Systemd bietet einige Werkzeuge, um den Boot-Prozess zu analysieren und zu optimieren. Diese Werkzeuge funktionieren alle unter einem Nutzerkonto, also gänzlich ohne Root-Rechte – der entsprechende Befehl lautet systemd-analyze.
Auf einer Workstation mit KDE und ziemlich vielen Diensten und SSD für das gesamte System fiel in unserem Test das Ergebnis nicht so gut aus (Listing 2, Zeile 1). Ein frisch installiertes aktuelles Notebook mit KDE startet dagegen schneller (Listing 2, Zeile 2). Mit einer leichteren Desktop-Umgebung kommen hier Werte von drei Sekunden in Reichweite.
Wenn der Start als zu lang erscheint, prüfen Sie mit systemd-analyze blame, welche Prozesse und Dienste dafür verantwortlich sind. Auf einem älteren Notebook brachte die Option blame an den Tag, dass der Dienst NTP über 30 Sekunden in der Schleife hing. Wie sich herausstellte, versuchte er, einen Server zu kontaktieren, der nicht mehr existierte. Ein Korrektur der Konfiguration behob das Problem.
Bei Bedarf erstellen Sie mittels systemd-bootchart eine Grafik, die das Verhalten der Prozesse beim Booten zeigt (Abbildung 6). Der Befehl hierzu lautet:
$ systemd-analyze plot > test.svg; inkscape test.svg
Zum Betrachten der Grafik dient in diesem Beispiel die Vektorzeichensoftware Inkscape. Alternativ klappt das aber auch mit Bildbetrachtern wie Gthumb oder dem Webbrowser Firefox.
Listing 2
Startup finished in 10.432s (kernel) + 6.287s (userspace) = 16.720s Startup finished in 1.327s (kernel) + 3.116s (userspace) = 4.443s
Abbildung 6: Mittels eines Bootcharts sehen Sie auf den ersten Blick, welche Dienste das System beim Starten aufhalten.
Fazit
Der Umstieg auf Systemd stellt weder Distributionen noch Anwender vor hohe Hürden. Für die nähere Zukunft bleibt Systemd kompatibel zu Sysvinit, sodass die bekannten Befehle zum Manipulieren von Diensten ebenso funktionieren wie die zum Herunterfahren, zum Neustart oder dem Wechsel des Runlevels.
Für Debian und Ubuntu erweist sich Systemd als gute Lösung: Damit stellen sie sich in die Reihe derer, die Systemd bereits benutzen wie etwa Fedora, OpenSuse, Arch Linux, Mageia und andere. Geht es nach den Entwicklern, trägt Systemd dazu bei, Prozesse für alle Distributionen zu standardisieren. Das bringt für die Entwicklung und Administration Vorteile. Detailliertere Informationen zu Systemd bietet das Blog von Lennart Poettering, das bisher bereits mehr als 20 Folgen umfasst [24].
Einige Entwickler werfen Red Hat vor, es strebe mit Systemd nach mehr Kontrolle über Linux. Mit Upstart zöge aber andererseits ein System ein, das derzeit völlig unter der Kontrolle einer Firma steht. Nüchtern betrachtet, handelt es sich bei Systemd um das technisch am besten geeignete Init-System für die absehbare Zukunft. Das musste selbst Debian einsehen, und es steht der Distribution gut an, dass sie sich hier offen nach vorne gibt.
Infos
[1] Poettering zu Kdbus: https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/13JZ7GpyVDb
[2] Sysvinit: http://de.wikipedia.org/wiki/SysVinit
[3] SMF: http://en.wikipedia.org/wiki/Service_Management_Facility
[4] Launchd: http://de.wikipedia.org/wiki/Launchd
[5] Upstart: http://de.wikipedia.org/wiki/Upstart
[6] OpenRC: http://en.wikipedia.org/wiki/OpenRC
[7] CLA: http://blog.tarent.de/2010/08/09/contributor-license-agreement-%e2%80%93-braucht-open-source-das/
[8] Kexec: http://en.wikipedia.org/wiki/Kexec
[9] Cgroups: http://www.golem.de/news/init-system-systemd-205-mit-veraenderter-cgroup-unterstuetzung-1307-100223.html
[10] Socket: http://de.wikipedia.org/wiki/Socket_(Software)
[11] Journal: http://0pointer.de/blog/projects/journalctl.html
[12] Logind: http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
[13] ConsoleKit: http://www.freedesktop.org/wiki/Software/ConsoleKit/
[14] Beschwerde auf Entwicklerliste: https://lists.debian.org/debian-devel/2013/10/msg00444.html
[15] Technisches Komitee: https://www.debian.org/devel/tech-ctte
[16] Antrag für CTTE: https://lists.debian.org/debian-devel/2013/10/msg00703.html
[17] Bug Report an das CTTE: https://lists.debian.org/debian-devel/2013/10/msg00825.html
[18] Torvalds zu CLAs: http://www.muktware.com/2014/01/linus-torvalds-cla-fundamentally-broken/19811/2
[19] Kroah-Hartman zu CLAs: https://plus.google.com/111049168280159033135/posts/NstZfwXbAti
[20] Garrett zu CLAs: http://mjg59.dreamwidth.org/29160.html
[21] 2. Fragensatz des CTTE: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5389
[22] General Resolution: http://www.debian.org/vote/
[23] Entscheidung des CTTE: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734
[24] Blog zu Systemd: http://0pointer.de/blog/projects/systemd.html
