Beim Wettstreit zwischen dem klassischen Init und dem recht jungen Systemd trifft jahrzehntelang gewachsene Technik auf neue Konzepte.

Direkt nach dem Booten des Kernels startet ein Dienst, der das restliche System und den weiteren Betrieb bis zum Herunterfahren begleitet. Er trägt stets die Prozess-ID 1 und hörte bislang auf Linux-Rechnern in der Regel auf den Namen init; das System dahinter nannte sich SysVinit [1]. Mit Systemd [2] drängt ein neues Programm an die gleiche Stelle. Allerdings gibt sich der Neue nicht immer gleich zu erkennen: Mit einer Abfrage über den Prozessstatus-Monitor Ps ermitteln Sie, ob das System den klassischen Init oder Systemd benutzt.

Mit den oft genutzten Optionen ax des Ps-Kommandos erhalten Sie allerdings auf einem von Systemd verwalteten Rechner nicht die korrekte Ausgabe (Listing 1, erste Abfrage). Erst wenn Sie die Option -e verwenden, liefert Ps ein korrektes Ergebnis (zweite Abfrage). Dasselbe gilt für ein System, das SysVinit benutzt (dritte Abfrage). Pstree liefert grundsätzlich eine zutreffende Ausgabe.

$ ps -ax | head -2
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:01 /sbin/init
$ ps -e | head -2
  PID TTY          TIME CMD
    1 ?        00:00:01 systemd
$ ps -e | head -2
  PID TTY          TIME CMD
    1 ?        00:00:00 init

Old School

Linux und artverwandte Systeme unterscheiden verschiedene Systemzuständen, die sogenannten Runlevel, denen gegebenenfalls Dienste (Daemons) zugeordnet sind. Die Tabelle “Runlevel” zeigt die für ein Linux-System typischen Zustände. Bis auf S erhalten dabei alle einen numerischen Wert zwischen 0 und 6. Die Runlevel von 2 bis 5 dienen je nach Distributionen unterschiedlichen Zwecken.

Welchen Runlevel das System beim Start standardmäßig anstrebt, können Sie der Datei /etc/inittab entnehmen; Listing 2 zeigt den entsprechenden Ausschnitt. Der Standard-Runlevel (initdefault) steht in der Zeile, die mit id beginnt – im Beispiel startet das System also in den Runlevel 2.

# The default runlevel.
id:2:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

Vor dem Standard-Runlevel durchläuft das System den Single-User-Modus (si:), ausgenommen bei Störungen während des Boot-Vorganges. Einen wichtigen Eintrag finden Sie in der letzten Zeile von Listing 2: Damit das System im Modus für Einzelbenutzer überhaupt funktioniert, führt Init einen automatischen Login für root aus.

Alles auf Start

Der Init-Prozess ruft die zum jeweiligen Runlevel gehörenden Start- und Stop-Skripte auf, um den gewünschten Zustand herzustellen. Bei Debian-basierten Systemen finden Sie diese unter /etc/init.d. Das Paketmanagement einer Distribution legt diese Skripte bei der Installation eines Diensts in der Regel an. Müssen Sie doch einmal ein solches Skript von Hand erstellen, sollten Sie sich an bereits existierende Dateien als Muster halten. Ändern Sie die Konfiguration eines Diensts, erlaubt es ein solches Skript, den Daemon zu stoppen und wieder zu starten oder den Status abzufragen (Abbildung 1). Die gewünschte Aktion – start, stop oder status – geben Sie beim Aufruf mit an.

Abbildung 1: Stoppen, Starten und den Status eines Dienstes abfragen – mittels Init-Skript brauchen Sie dazu nur das passende Schlüsselwort als Parameter.

Richtig abgelegt

Alle im Folgenden angegebenen Pfade beziehen sich auf Debian und verwandte Systeme. Andere Distributionen verwenden oft alternative Verzeichnisse.

Für jeden Runlevel existiert ein eigenes Verzeichnis, in dem sich Links befinden, die nach /etc/init.d/Skript zeigen. Der Name des symbolischen Links beginnt bei einem Startskript mit einem S, ein führendes K kennzeichnet das Skript zum Beenden (“Kill”). Es folgt eine Nummer, die die Reihenfolge bestimmt, in der das System die Skripte abarbeitet. Installieren Sie Dienste per Paketmanagement, erhalten die Links die passenden Namen; bei selbst kompilierten Programmen müssen Sie selbst Hand anlegen, auch hinsichtlich der Reihenfolge. So funktioniert beispielsweise ein Webserver erst dann ordnungsgemäß, wenn das Netzwerk bereits läuft.

Im klassischen Init-System von Debian liegen unter /etc die Verzeichnisse für die Runlevel: rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d und rcS.d. Bei Debian 7 enthalten rc3.d, rc4.d und rc5.d fast identische Daten wie rc2.d, kommen aber in der Regel nicht zum Einsatz. Sie bieten damit die Möglichkeit, eigene Vorstellungen zu verwirklichen [3].

Das Skript für den Dienst atd liegt auf einem solchen System mit gleichem Namen unter /etc/init.d. Unter /etc/rc2.d befindet sich der Link S15atd für den Start. Die Links, die der Init-Prozess aufruft, um diesen Daemon zu beenden, liegen in mehreren Verzeichnissen: rc0.d, rc1.d und rc6.d und heißen jeweils K01atd.

Konfiguration

Die Datei /etc/inittab definiert nicht nur das Standard-Runlevel, sondern steuert das Verhalten des Systems auch über weitere Einträge, die in der folgenden Form vorliegen:

id:Runlevel(s):Aktion:Kommando

Das erste Feld bezeichnet den Eintrag eindeutig und einmalig. Im zweiten Feld führen Sie einen oder mehrere Runlevels auf, für die der Eintrag gilt. Bei mehreren Einträgen sortieren Sie diese aufsteigend. Das dritte Feld gibt die Art der gewünschten Aktion an, deren Bedeutung die Tabelle “Aktionen” aufführt.

In Listing 3 finden Sie einen weiteren Auszug aus /etc/inittab. Zu Beginn steht die Anweisung, den Durchlauf des Skripts /etc/init.d/rc für den angegebenen Runlevel abzuwarten. Zeile 12 definiert, was beim Drücken von [Strg]+[Alt]+[Entf] geschehen soll – in diesem Fall für alle Runlevel außer 0 und 6 ein Neustart des Rechners. Die Einträge pf, pn und po regeln, wie das System beim Stromausfall bei vorhandener USV reagiert.

Der Block ab Zeile 33 aktiviert die Konsolen. Die erste (tty1) kommt in den Runleveln 1 bis 5 zum Einsatz. Die virtuellen Konsolen tty2 bis tty6 sind den Runleveln 2 und 3 vorbehalten. Auf tty7 liegt bei Debian die grafische Oberfläche. Benötigen Sie zusätzliche virtuelle Konsolen, bestünde die Möglichkeit, ab tty8 weitere anzulegen.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Den laufenden und vorhergehenden Runlevel ermitteln Sie über die Anweisung who -r (Abbildung 2). Den Wechsel eines Runlevels – dazu gehört auch das Anhalten oder Neustarten des Rechners – nehmen Sie mit den Kommandos aus der Tabelle “Runlevel-Wechsel” vor. Mit dem Befehl kill -1 1 liest Init seine Konfiguration neu ein, ohne dass dazu das System neu starten müsste. Mittels kill -9 1 fahren Sie das System herunter.

Abbildung 2: Mit einem einfachen Kommando ermitteln Sie den aktuellen und den vorhergehenden Runlevel.

Eigenschaften von Systemd

Im Gegensatz zu Init startet Systemd die gewünschten Dienste parallel, was das Laden des Betriebssystems beschleunigt. Damit das gelingt, legt der Daemon Sockets an, über die die Dienste kommunizieren, und puffert die an die Programme gerichteten Daten so lange, bis diese erfolgreich starten. Stürzt ein Dienst ab, startet Systemd ihn neu. Die Zugriffe der Client-Anwendungen landen während dieser Phase wieder im Puffer; anschließend arbeitet der Daemon sie dann ab. Das Konzept erlaubt es, von Systemd angelegte Sockets zwischen Programmen zu verschieben.

Neuere Kernel stellen eine Funktion namens Cgroup [4] bereit, die es erlaubt, Prozesse mit ihren Kindprozessen in hierarchisch aufgebauten Gruppen zusammenzufassen. Systemd erstellt für jeden Dienst eine eigene Cgroup, die ihren Namen entsprechend dem Dienst erhält. Dieses Konzept beseitigt das Chaos, das in der Vergangenheit durch externe Prozesse entstand, die viele Dienste starten. Ferner vermeidet es, dass bei einem Absturz des Diensts einige dieser externen Prozesse weiterlaufen.

Es brauchen nicht alle Dienste beim Start des Systems loszulaufen, vielmehr geschieht dies bei Bedarf. Dazu überwacht Systemd die Aktivität auf einem Netzwerk- oder IPC-Socket oder einem FIFO-Puffer. Insofern übernimmt der Daemon hier teilweise die Funktionalität von Inetd. Darüber hinaus erlaubt es das Konzept der Software, viele Aufrufe ohne administrative Rechte vorzunehmen. Systemd verwaltet außerdem die Mountpoints, erstellt auf Wunsch Snapshots des Systems und stellt diese bei Bedarf wieder her. Diese Aggregation von Funktionen, die weit mehr als die hier stellvertretend genannten umfasst, brachte dem Ansatz erhebliche Kritik ein.

Die Runlevel existieren in Form von Zielen (“Targets”) weiter. Meist geht aus den Namen der Dateien mit der Endung .target deren Zweck hervor. So regelt die Datei halt.target das Herunterfahren des Systems. Die Datei /etc/inittab spielt für Systemd keine Rolle mehr. Allerdings unterstützt der Daemon die traditionellen Skripte zum Verwalten der Dienste.

Je nach verwendeter Distribution unterscheiden sich die Äquivalente zwischen Runleveln und Targets. Die Tabelle “Runlevel vs. Targets” bietet eine Gegenüberstellung, die Angaben stammen von einer Installation mit Debian 8. Darüber hinaus gibt es weitere Targets, die es ermöglichen, die Zustände des Systems feiner zu unterteilen.

Systemd konfigurieren

Die Anweisungen für die Konfiguration und zum Ausführen von Programmen liegen bei Systemd in Unit-Dateien. Die Endung der Dateien gibt einen Aufschluss darüber, welche Funktion eine Unit hat – eine Zusammenstellung dazu finden Sie in der Tabelle “Units”. Die einzelnen Konfigurationsdateien liegen als Klartext vor und weisen einen ähnlichen Aufbau wie Ini-Dateien auf, was es ermöglicht, sie mit einem Texteditor zu bearbeiten.

Grundsätzlich liegen diese Dateien und die symbolischen Links hierzu unter /lib/systemd, damit die Software diese beim Booten erreicht. Zumindest bei Debian finden sich weitere Unit-Dateien unter /usr/lib/systemd. Geänderte Unit-Dateien befinden sich unter /etc/systemd/system. Vom System selbst zur Laufzeit geschaffene Dateien finden Sie unter /run/systemd/system. Listing 4 zeigt den Aufbau einer Unit-Datei für den At-Daemon.

[Unit]
Description=Deferred execution scheduler
Documentation=man:atd(8)
[Service]
ExecStart=/usr/sbin/atd -f
IgnoreSIGPIPE=false
[Install]
WantedBy=multi-user.target

Eigene Unit-Dateien

Falls Sie in den Ablauf beim Booten eingreifen möchten, empfiehlt es sich, beim Anlegen oder Ändern von Unit-Dateien einige Regeln zu beachten. Möchten Sie eine Datei ändern, kopieren Sie diese zuerst von /lib/systemd/ nach /etc/systemd/system/. Neue Unit-Dateien legen Sie ebenfalls dort an: Geänderte oder neue Dateien unter /lib/systemd/ überschreibt das System unter Umständen.

Die Unit-Dateien bestehen aus verschiedenen Sektionen, denen Sie wiederum Anweisungen zuordnen. In der Tabelle “Sektionen und Anweisungen” finden Sie eine Auswahl dazu. In einer Unit-Datei kommt immer nur eine Sektion zusätzlich zum Abschnitt [Unit] und gegebenenfalls [Install] vor.

Beispiel in Eigenbau

Das Shellskript aus Listing 5 liefert in Intervallen eine Übersicht aller im Netz befindlichen Hosts. Die Ergebnisse betrachten Sie mittels tail -f /tmp/netzliste.txt in einem Terminal. Legen Sie zunächst das Skript im Verzeichnis /usr/sbin als netzschau.sh an. Mittels chmod 700 netzschau.sh vergeben Sie die passenden Rechte. Damit Systemd das Programm startet, legen Sie unter /etc/systemd/system die Unit-Datei netzschau.service (Listing 6) an.

#! /bin/sh
while true;
do
echo "Übersicht aktiver Netzwerkteilnehmer" > /tmp/netzliste.txt
echo "------------------------------------" >> /tmp/netzliste.txt
date +%d.%m.%Y-%H:%M:%S >> /tmp/netzliste.txt
echo "------------------------------------" >> /tmp/netzliste.txt
# Fping ausführen und Ausgabe in Log-Datei speichern
fping -r 0 -g 192.168.0.0/24 > fping.log 2>&1
# Ausfiltern der nicht erreichbaren Hosts
grep "alive" fping.log | sort  >> /tmp/netzliste.txt
echo "------------------------------------" >> /tmp/netzliste.txt
sleep 120
done

[Unit]
Description=Auflistung aktiver Hosts
Documentation=man:fping(8)
[Service]
ExecStart=/usr/sbin/netzschau.sh
IgnoreSIGPIPE=false
[Install]
WantedBy=multi-user.target

Nun weisen Sie Systemd an, die Unit-Datei zu verarbeiten und die Anwendung zu starten. Für den dauerhaften Start aktivieren Sie den Dienst mittels des Befehls aus der ersten Zeile von Listing 7. Dabei legt das System den notwendigen symbolischen Link ins Target-Verzeichnis multi-user.target. Sie starten den Dienst mittels des Befehls aus der zweiten Zeile. Der Befehl aus der letzten Zeile prüft, ob das Programm läuft. Abbildung 3 zeigt das Ergebnis der Statusabfrage.

$ systemctl enable netzschau.service
$ systemctl start netzschau.service
$ systemctl status netzschau.service

Abbildung 3: Bei Bedarf fragen Sie den Status eines laufenden Diensts ab, um zu sehen, ob die Software noch ordnungsgemäß läuft.

Systemctl dient in der Systemd-Welt als zentrales Werkzeug zum Steuern von Aktionen. Ohne weitere Angabe listet es alle Units auf, die das System nach dem Booten gestartet hat. Die Tabelle “Systemctl-Parameter” listet die wichtigsten Argumente für das Tool, mit denen Sie das System über die Unit-Dateien administrieren.

Viele Parameter erlauben es, über zusätzliche Angaben die Aktion zu präzisieren. Abbildung 4 zeigt ein komplett durchgespieltes Beispiel: Es geht darum, einen Dienst – in diesem Fall das RDBMS PostgreSQL – anzuhalten, zu maskieren und anschließend diese Maßnahme wieder rückgängig zu machen. Die Unit-Datei liegt dabei nicht unter /etc/systemd/system. Bei der Abfrage des Status finden Sie alle zum Dienst gehörenden Prozesse angegeben. Ferner zeigt der Aufruf den Status der Unit selbst und deren Laufzeit an.

Abbildung 4: Sind die einschlägigen Parameter erst einmal verinnerlicht, geht die Arbeit mit Systemctl vergleichsweise reibungslos von der Hand.

Eine Aufstellung aller Unit-Dateien erhalten Sie mittels systemctl list-unit-files (Abbildung 5). Neben den Zuständen enabled, disabled und masked finden Sie hier noch static: Es signalisiert, dass die entsprechende Unit-Datei nicht aktiviert ist und in der Sektion [Install] obendrein Anweisungen hierzu fehlen. Ein Steuern durch Systemctl gelingt daher nicht. Manchmal liegt hier ein Fehler vor; es gibt aber auch verschiedene plausible Gründe für den Zustand static: Eventuell ist die Unit in anderen Units unter .wants oder .requires eingetragen. Eine weitere Möglichkeit: Das System aktiviert sie per Socket, Timer, D-Bus oder Udev.

static weisen entweder einen Konfigurationsfehler auf, oder es handelt sich um Abhängigkeiten, die andere Unit-Dateien voraussetzen.” width=”283″ height=”300″ /> Abbildung 5: Unit-Dateien mit dem Status static weisen entweder einen Konfigurationsfehler auf, oder es handelt sich um Abhängigkeiten, die andere Unit-Dateien voraussetzen.

Systemd weist jeden Dienst, den es verwaltet, in eine eigene Cgroup ein. Mit dem Befehl systemctl-cgls sehen Sie auf einen Blick, welche Prozesse zu welcher Unit gehören. Sie erhalten damit eine Ansicht ähnlich der von Pstree (Abbildung 6).

systemd-cgls sehen Sie auf einen Blick, zu welcher Cgroup und somit zu welchem Dienst ein Prozess gehört.” width=”300″ height=”193″ /> Abbildung 6: Mit dem Befehl systemd-cgls sehen Sie auf einen Blick, zu welcher Cgroup und somit zu welchem Dienst ein Prozess gehört.

Das Programm Systemadm ermöglicht das schnelle und einfache Verwalten von Systemd und den Diensten. Mit dem Tool erledigen Sie per Mausklick im Prinzip die gleichen Aktionen wie mit Systemctl auf der Kommandozeile (Abbildung 7).

Abbildung 7: Systemadm erlaubt es, Systemd und die von diesem verwalteten Dienste via Mausklick zu steuern.

Journal statt Log

Manche Distributionen ersetzen Syslog durch Systemd-journald, das die Log-Dateien oft nur zur Laufzeit aufbewahrt. Falls Sie dies nicht wünschen und die von Ihnen eingesetzte Distribution es nicht bereits geändert hat, passen Sie einige Einträge in /etc/systemd/journald.conf entsprechend an. Durch Setzen von Storage=persistent landen die Daten dauerhaft unter /var/log/journal im Dateisystem. Sie begrenzen die Größe des Logs über eine Angabe wie SystemMaxUse=100M. Bedenken Sie, dass sich die Dateien nicht mit den üblichen Werkzeugen für Textdateien durchsuchen lassen, wie etwa Grep: Dazu dient das Programm Journalctl.

Geben Sie das Kommando journalctl ohne weitere Option ein, bekommen Sie das komplette Journal aufgelistet. Die Tabelle “Journalctl-Optionen” zeigt einige Möglichkeiten, um die oft sehr umfangreiche Ausgabe auf die gesuchten Informationen zu begrenzen. Abbildung 8 zeigt eine Abfrage, deren Ausgabe sich auf einen einzelnen Dienst (apache2.service) beschränkt.

Abbildung 8: Dank der richtigen Optionen schränken Sie die Flut an Informationen aus dem Journal von Systemd ein und gelangen so direkt zu den gesuchten Daten.

Fazit

Die beiden Ansätze, SysVinit und Systemd, verfolgen sehr unterschiedliche Konzepte. Das althergebrachte Init-System macht es dem Administrator sehr leicht: Mehr als Shell-Kenntnisse und einen Editor benötigen Sie nicht, um die entsprechenden Dateien zu erstellen und zu bearbeiten.

Systemd entstand in erster Linie aus dem Gedanken heraus, den Start des Rechners zu beschleunigen. Mittlerweile hat der Daemon aber seine Arme krakengleich in viele Bereiche des Systems ausgestreckt – sehr zum Unmut einiger Benutzer. Trotzdem gehört der Technik wohl die Zukunft: Nach und nach springen immer mehr Distributionen auf den fahrenden Zug auf.