create mobile friendly website
Booten unter Linux

Booten unter Linux

Systemd: Neuer Herrscher auf dem Linux-System?

In den freien Distributionen ist es schon so weit, in den kommenden Enterprise-Versionen wird er Einzug halten: Systemd ersetzt den alten SysVinit-Daemon. Systemd bietet dabei eine Menge neuer Funktionen, neue Kommandos und führt dazu, dass Administratoren sich neues Wissen aneignen müssen. Dieser Artikel gibt einen Einblick in die wichtigsten Funktionen von Systemd.


Damals bis heute

Traditionell ist Init (SysVinit) der erste Prozess, der auf einem Unix/Linux-System gestartet wird. Mit Hilfe der
Konfigurationsdatei /etc/inittab werden Start/Stopp-Skripte in einer bestimmten Reihenfolge gestartet bzw. gestoppt. Die Dienste werden hierbei seriell gestartet und Init fühlt sich nach dem Starten nicht mehr für die jeweiligen
Dienste zuständig. Der Begriff „Runlevel“ wird genutzt, um bestimmte Zustände zu erreichen. Letztendlich wird für
jeden Runlevel eine bestimmte definierte Anzahl an
Skripten ausgeführt. Init, welches aus einem Design von 1983 entstammt, hat inzwischen einige gravierende Nachteile:

  • Die Start/Stopp-Skripte werden sequentiell ausgeführt Erst wenn das eine Skript fertig ist, wird das nächste ausgeführt. Bei vielen Skripten mit langer Ausführungsdauer macht sich dies negativ beim Startvorgang bemerkbar.
  • Die Start/Stopp-Skripte sind teilweise sehr komplex und beinhalten sehr viele Shellskripte. Teilweise wird versucht Abhängigkeiten innerhalb der Skripte aufzulösen.
  • Start/Stopp-Skripte sind distributionsabhängig und haben häufig unterschiedliche Inhalte und andere Rückgabewerte.
  • Dienste, die gestartet werden sollen, werden immer ausgeführt, auch wenn sie erst Wochen oder Tage später benötigt werden (z.B. der Drucker-Spooler).
  • Init bekommt es nicht mit, wenn sich ein Dienst zur Laufzeit beendet.
  • Eine Protokollierung über Syslog findet erst nach dem Start des Syslog-Daemon statt. Meldungen davorlanden im Nirwana.

Der Neue: Systemd

Systemd [1] soll in Zukunft die Aufgabe des Init-Daemons übernehmen, die bisherigen Nachteile ausmerzen und weitere nützliche Funktionalitäten implementieren. Systemd stellt sich hier als System- und Servicemanager dar. Hauptsächlich wird es von Lennart Poettering [2] und Kay Sievers von Red Hat entwickelt und als freie Software unter der LGPL (Lesser General Public License) [3] ver­öffentlicht.
Systemd ist abwärtskompatibel und kann auch weiterhin die alten Init-Skripte ausführen. Es baut auf Funktionen
(z.B. cgroups) auf, die es aktuell nur im Linux-Kernel gibt, sodass eine Portierung auf anderen Unix-Systeme
momentan nicht möglich und auch nicht vorgesehen ist.
Systemd beseitigt die eingangs genannten Nachteile und bietet unter anderem folgende Fähigkeiten:

  • Bei Systemd wird die Arbeitsweise von den vielen einzelnen Start/Stopp-Skripten verlagert. Zukünftig werden zum Starten/Stoppen von Diensten keine Shell-Skripte mehr geschrieben, sondern einfache „Unit-Files“ erstellt, die alle notwendigen Anweisungen enthalten.
  • Systemd kann genau feststellen, ob ein Dienst gerade läuft und kann diesen auch zuverlässig beenden.
  • Der Ersatz der Runlevel wird als „Targets“ bezeichnet. Diese können unabhängig von der aktuellen Position und von später manuell nachgestarteten Dienste ziel­sicher erreicht werden.
  • Socket-Aktivierung: Eine besonders pfiffige Funktion, welche zunächst einen Socket erstellt, den Dienst aber erst später startet.
  • Systemd verhält sich auf jedem Linux-Derivat gleich,
  • sodass alle Dienste in Zukunft immer gleich gehandhabt werden können.
  • Systemd und seine Komponenten können online aus­getauscht und aktualisiert werden, ohne dass ein Neustart des kompletten Betriebssystems notwendig ist.
  • Systemd nutzt die Cgroups des Linux-Kernel zur Gruppierung und Ressourcenzuweisung von Prozessen.

Verschwundene Meldungen

Wird ein Linux-System mit SysVinit gebootet, werden Meldungen für das Starten und Stoppen der Dienste ange­zeigt. Um den Boot-Vorgang zu beschleunigen und das Starten der Dienste zu parallelisieren, werden diese Meldungen bei Systemd unterdrückt. Häufig wird anstelle der Meldungen eine Grafik mittels Plymouth angezeigt. Ob die Dienste erfolgreich oder gar nicht gestartet wurden, kann im Nachhinein für alle eingesehen werden.

Verwaltung von Systemd

Der wichtigste Befehl zur Administration von Systemd ist systemctl. Dieser Befehl ermöglicht unzählige Kommandos, sogenannte „Unit-Commands“, mit denen Systemd gesteuert wird. Im Regelfall wird dieser Befehl vom Benutzer root verwendet. Einige Unterkommandos können auch von normalen Benutzern verwendet werden, wie zum Beispiel die Statusabfrage eines Dienstes, ob er läuft oder nicht. Wird das Programm ohne zusätzliche Parameter aufge­rufen, erhält der Benutzer eine Liste von „Units“, die beim Systemstart abgearbeitet werden. Das sind zum einen das Starten von Diensten, aber auch das Laden von Treibern, das Prüfen und Einhängen von Dateisystemen.

Mit dem Kommando systemctl list-unit-files werden alle vorhandenen Units aufgelistet. Die Abbildung 1 zeigt einen Auszug der Ausgabe. In aktuellen Linux-Versionen kann die Liste bereits über 300 Units enthalten. Reicht bei der Ausgabe von systemctl eine Seite nicht aus, wird automatisch less verwendet, wodurch in der Ausgabe navigiert werden kann. Alles was Systemd kontrolliert und steuert wird als „Unit“ bezeichnet. Units, mit denen man am häufigsten zu tun hat, sind die „Service-Units“, welche für die Kontrolle von klassischen Hintergrunddiensten zu­ständig sind.

Möchte man einen Dienst, beispielsweise Postfix starten, stoppen oder den Status ermitteln, kann dies mittels systemctl start|stop|status postfix.service erfolgen. Bei Service-Units kann das .service auch weggelassen werden, da Service-Units der Standard sind.

Mittels systemctl enable|disable postfix.service kann ein Dienst dauerhaft aktiviert oder deaktiviert werden. Wird der Status eines Dienstes angezeigt, werden auch immer die letzten dazugehörigen Syslog-Meldungen ausgegeben oder auch, dass der Dienst aus irgendwelchen Gründen nicht mehr läuft.

Systemd interessiert sich für Dinge, die durch ihn gestartet wurden, der Administrator sollte in Zukunft immer systemctl zum Stoppen von Diensten nutzen. Wird ein kill für die Beendigung eines Prozesses ausgeführt, dauert es meistens nicht lange und der Dienst wird von Systemd wieder nachgestartet.

Von Units zu Targets

Die verschiedenen Dateien, in denen die einzelnen Units abgelegt sind, liegen unter /usr/lib/systemd/system. Die Vorgaben des Herstellers würden überschrieben, wenn eine Datei mit gleichem Namen im Verzeichnis /etc/systemd/system liegt. Die Unit-Files bestehen nicht aus unzähligen Zeilen Shellcode, sondern aus wenigen definierten Schlüssel­wörtern. Ein Beispiel für den Aufbau einer Unit-Datei zeigt die Abbildung 2.

Die Target-Units bilden das Gegenstück zu einem Runlevel unter dem klassischen SysVinit. Aus Kompatibilitätsgründen bringt Systemd sogar äquivalente Targets mit, mit denen die alten Runlevels abgedeckt werden. Das Kommando systemctl --type target listet alle vorhandenen Targets auf. Die Targets können direkt am Bootmanager als Kernel-Parameter angegeben werden. Ein systemd.unit=multi-user.target würde also in das Target booten, welches einem Runlevel 3 unter einem SuSE Linux Enterprise Server entspricht.


Soll ein bestimmtes Target als Standard eingerichtet werden, kann dies über einen symbolischen Link erfolgen: ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target.
Natürlich können Targets auch während des laufenden Betriebes gewechselt werden. Der Kommando systemctl isolate graphical.target startet zusätzlich einen grafischen Displaymanager.

Nur noch Units

Systemd ist nicht nur für das Starten und Stoppen von Diensten beim Booten eines Systems zuständig, sondern auch für viele weitere Funktionalitäten, wie zum Beispiel das Prüfen und Einhängen von Dateisystemen, das zyklische Leeren von temporären Verzeichnissen, das automatische Neustarten von Diensten bei Konfigurationsänderungen und vieles mehr. Aktuell gibt es 12 verschiedene Units, die für unterschiedliche Aufgaben genutzt werden können. Jede Unit ist in einer eigenen detaillierten Manual Page beschrieben. Service-Units werden beispielsweise unter man systemd.service erläutert. Einige häufig genutzte Units sind:

  • Service-Units: Starten und Stoppen von Diensten und Kontrolle der zugehörigen Prozesse
  • Socket-Units: Erstellen von lokalen (IPC) oder netzwerkbasierten Sockets, um Dienste erst bei deren Nutzung zu starten
  • Target-Units: Gruppieren von Units zu einem Target
  • Mount-Units: Mounten von Dateisystemen (Systemd erstellt automatisch für alle Einträge aus /etc/fstab eine eigene Mount-Unit)
  • Automount-Units: Mounten von Dateisystemen bei Bedarf, zum Beispiel bei Zugriff auf ein Verzeichnis
  • Snapshot-Units: Momentaufnahme bestehender Units, zu denen später wieder gewechselt werden kann
  • Swap-Units: Aktivierung von Swap-Partitionen
  • Path-Units: Aktivierung von Diensten, wenn sich bestimmte Dateien verändert haben

Ein eigener Logging-Daemon

Normalerweise wird das Logging von Meldungen mittels eines Syslog-Daemon durchgeführt. Systemd bringt einen eigenen Protokollierungsdienst namens systemd-journald (kurz Journald) mit, der Meldungen in binäre Dateien schreibt. Häufig kam es in der Vergangenheit vor, dass Meldungen in unterschiedlichen Log-Dateien abgelegt wurden, sodass im Fehlerfall in mehreren Dateien gesucht werden musste. Darüber hinaus konnte es passieren, dass man übergroße Log-Dateien mit verschiedenen Meldungen hat und man sich die gewünschten erst heraussuchen muss. Journald soll das Protokollieren und Auswerten verbessern. Auf alle Meldungen wird mit nur einem einzigen Befehl namens journalctl zugegriffen.

Eine Übersicht aller Log-Meldungen, inklusive der schon rotierten, erhält man mit dem einfachen Aufruf von journalctl. Das Ausgabeformat ähnelt dem des alten Syslog-Daemon, sodass keine Umgewöhnung notwendig ist. Häufig wird zum Ansehen auflaufender Syslog-Meldungen tail -n 100 -f genutzt. Diese Optionen sind bei Journald ebenfalls verfügbar: journalctl -n 100 -f zeigt die letzten 100 Meldungen und weiterhin neue Meldungen an. Da Journald selbständig Indizes für die Log-Meldungen erstellt, kann auch schnell und einfach nach Meldungen gesucht werden. Das Kommando
journalctl -u dnsmasq --since='2014-07-17 11:00' --until='2014-07-17 12:00' gibt Meldungen zu einer bestimmten Unit für einen bestimmten Zeitraum aus. Ein Beispiel der Ausgabe ist in Abbildung 3 dargestellt. Die möglichen Optionen zur Benutzung von journalctl, sind in der gut dokumentierten Manual Page ersichtlich.

Fazit

Systemd kommt aktuell in allen Linux-Distributionen zum Einsatz und wird den klassischen SysVinit ersetzen. Admini­stratoren müssen sich an neue Kommandos ge­wöhnen und ihr Know-how erweitern. Insgesamt wird Systemd viele Unterschiede, die es in verschiedenen Distributionen gab, vereinheitlichen. Aktuell werden immer mehr Fähigkeiten, die bisher von eigenen Diensten bereitgestellt wurden, in Systemd integriert. Schon heute besitzt Systemd einen eigenen Logging-Daemon, einen NTP-Client, eine Netzwerkkonfiguration und vieles mehr. Die Befehle und Komponenten von Systemd sind mittels der Manual Pages gut dokumentiert.

Systemd wird sicherlich in Zukunft über das Linux-System herrschen.

Christian Fertsch ()

ORDIX aktuell

Duales Studium bei der ORDIX AG – Dein Weg in die IT!
Du bist gerade mit Deinem Abitur fertig, wissbegierig und möchtest den ersten Grundstein für Deine berufliche Zukunft l...
Weiterlesen ...
Soziales Engagement – Die ORDIX AG unterstützt gemeinnützige Organisationen zu
Weihnachten
Die Unterstützung von karitativen Organisationen ist ein wesentlicher Bestandteil der ORDIX Philosophie. Es ist zur Trad...
Weiterlesen ...

Kostenloses Kundenmagazin

Abbildungen

Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum

Impressum der ORDIX® news 3/2014

Links

[1] Projektseite von Systemd
[2] Webseite von Lennart Poettering
[3] Informationen zur LGPL

Bildnachweis

© stockvault | Grunge texture | Bjorgvin Gudmundsson
© freepik.com | Vector doors graphic elements
© flickr | Penguins | Christopher.Michel