16.6 Initialisierung

16.6.1 Runlevel

Und dann wären da noch die Runlevel: Während des Systemstarts werden verschiedene Stufen durchlaufen, für die jeweils Skripte abgearbeitet werden. Diese befinden sich im Systemverzeichnis /etc/init.d. Die Reihenfolge, in der die Skripte in den einzelnen Stufen (Runleveln) durchlaufen werden, ist in Unterverzeichnissen /etc/rc.Xd abgelegt.

Im Einzelnen unterscheidet man die folgenden Runlevel:

• Runlevel 0 Anhalten des Systems bzw. kontrolliertes Herunterfahren in den Systemhalt.

• Runlevel 1 Hierbei handelt es sich um den Einzelbenutzermodus, d. h., es kann maximal ein Benutzer mit dem System arbeiten.

• Runlevel 2–5 Volle grafische Runlevel mit Multiuser- sowie Netzwerkfähigkeiten. Dies ist mittlerweile der Standard-Runlevel bei modernen Debian- und Ubuntu-Versionen. Zwischen den Runleveln 2–5 werden keine Unterschiede mehr gemacht.

• Runlevel 6 Reboot (Neustart) des Systems.

Der Übergang in die einzelnen Runlevel kann vom Superuser unter Verwendung des Kommandos init herbeigeführt werden. Loggen Sie sich zu diesem Zweck einmal als Root ein, und versuchen Sie, das System von der Konsole aus neu zu starten: sudo init 6.

Nun können Sie auch einmal versuchen, in den Singleuser-Modus via init 1 zu wechseln: Dabei öffnet sich eine Linux-Konsole. Apropos Kommandozeile: Im Multiuser-Modus können Sie jederzeit mittels + + Funktionstaste auf eine Konsole Ihrer Wahl im textbasierten Modus wechseln. , und sind Standardkonsolen, ist die Grafikkonsole. Das ersetzt quasi mehrere Fenster, falls Sie sich im Runlevel 1 oder 3 befinden.

16.6.2 init

In Abschnitt haben Sie kurz die Runlevel kennengelernt, die vom Sys-V-init (init auf System-V-orientierten Systemen) verwaltet werden. Das Sys-V-init wird heutzutage von fast allen UNIX-Systemen verwendet und stellt das standardmäßige Boot-Konzept dar. Genauer gesagt handelt es sich bei Sys-V-init um den Prozess, der als Erstes vom Kernel gestartet wird und daher die Prozess-ID 1 bekommt. Dieser Prozess nun startet anhand der gewünschten Runlevel die benötigten Systemdienste. Der Ablauf ist fest vorgegeben und normalerweise unter Linux in der Datei /usr/src/linux/init/main.c festgelegt.

Die Aufgaben von init sind mannigfaltig. Am Anfang wird init (oder Sys-V-init) vom Kernel gestartet. Dies ist der erste Prozess, und er bekommt folgerichtig die Prozess-ID 1. Init startet nun im Userspace alle weiteren nötigen Prozesse und initialisiert den Rechner. Es werden nun Kernel-Module geladen, Netzwerke eingerichtet, Dateisysteme gemountet, Serverdienste gestartet und letztendlich der grafische Login-Manager gdm geladen. Dass dies alles in einer vernünftigen Reihenfolge geschehen muss, leuchtet sofort ein, denn z B. macht die Synchronisation der Systemzeit erst Sinn, wenn zuvor die Netzwerk-Hardware korrekt initialisiert und eingerichtet wurde.

16.6.3 Upstart

Wenn man sich die Vorgehensweise von init verinnerlicht (siehe Abschnitt), tritt eine deutliche Schwäche dieses Systems hervor: Aufgrund seiner Konzeption startet Sys-V-init in den Runlevel, die Prozesse immer in einer vorgegebenen Reihenfolge und startet einen Prozess meist erst dann, wenn der vorherige Prozess fertig initialisiert wurde und damit abgeschlossen ist. Dieses Schritt-für-Schritt-Vorgehen macht den Boot-Vorgang sehr zuverlässig, aber leider auch relativ langsam.

Schon seit Längerem gibt es verschiedene Versuche, dieses Konzept zu überarbeiten oder wenigstens zu modifizieren. So gibt es zum Beispiel bei einigen Linux-Distributionen (z. B.Gentoo Linux) Umsetzungen, alle Prozesse in einem Runlevel gleichzeitig starten zu lassen. Diese Modifikationen beschleunigen zwar den Startprozess geringfügig, können aber natürlich bei anderen Problemen, wie z. B. bei wechselnder Hardware im laufenden Betrieb, keine Akzente setzen. Alternativen zu init gab es in der Vergangenheit zuhauf. Beispiele sind hier InitNG, eINIT und Launchd in Mac OS X.

Nun ist die Anzahl der zu startenden Dienste aufgrund der Komplexität moderner Hardware und veränderten Bedürfnissen der Benutzer in den letzten Jahren stetig gewachsen. Von einem Betriebssystem wird heutzutage erwartet, dass es spielend leicht und schnell mit wechselnden Mobilgeräten umgehen kann, wie sie z. B. oft per USB an den Rechner angeschlossen werden. Es muss somit dynamisch seine Systemkonfiguration ändern können.

Ziel vs. Ereignis

Upstart (http://upstart.ubuntu.com) ist der Name eines völlig neuartigen Konzepts, das eine völlige Abkehr von init darstellen soll. Die bisherigen Konzepte haben eines gemeinsam: Sie sind zielorientiert. Dies bedeutet, dass vorher festgelegt wird, welche Dienste am Ende des Startvorganges laufen sollen. Die Abhängigkeiten werden vorher in einer sinnvollen Reihenfolge definiert. Upstart hingegen soll ereignisorientiert sein. Bei dieser Vorgehensweise lauern die Dienste im Hintergrund und starten erst dann, wenn alle Vorbedingungen erfüllt sind. Dies sind die sogenannten »Events«. Beispiel: Wenn Sie einen USB-Stick an den Rechner stecken, löst dies ein Event aus, das dazu führt, dass der USB-Stick gemountet wird.

Die Events werden in die folgenden drei Klassen eingeteilt:

Upstart soll nicht nur das Booten des Sytems beschleunigen, sondern auch das dynamische Verwalten von Diensten. Dies betrifft folgende Bereiche, die mit Upstart vereinheitlicht und verwaltet werden sollen:

• Viele Dienste hängen vom Funktionieren bestimmter Hardware ab. So können manche Dienste erst gestartet werden, wenn die dazu nötige Netzwerkverbindung ad hoc aufgebaut wurde.

• Die Dynamik der Dienste-Verwaltung betrifft auch zeitabhängige Prozesse. So gibt es Services wie Cron oder den Anacron, die bestimmte Prozesse zu festgelegten Zeitpunkten starten.

Die Entwicklung steht noch am Anfang, aber die erste Implementation dieses neuen Konzeptes hat 2006 Einzug in die regulären Ubuntu-Versionen und inzwischen auch in die testing-Version von Debian gehalten. Um den reibungslosen Betrieb der Distributionen nicht zu gefährden, erfolgen große Teile der Initialisierung mithilfe des Kompatibilitätsskriptes <I>/etc/init.d/rc<P> durch die herkömmlichen init-Dateien. Die Ausweitung auf Teile des Systemstarts erfolgt kontinuierlich in neueren Ubuntu-Versionen, wobei temporale Events noch nicht integriert sind.

Start-Analyse

Der Systemstart (Version 7.10, Upstart 0.3.8) erfolgt recht zügig. Allerdings sind die Unterschiede aufgrund des Kompatibilitätsmodus marginal. Testmessungen zeigen Unterschiede im Bereich von wenigen Sekunden. Zur Auswertung eignet sich das Tool Bootchart, das Sie über die Quellen von Ubuntu bekommen (siehe Abbildung). Dieses Messwerkzeug protokolliert während des Startvorgangs in einem Takt von 0,2 Sekunden die CPU-Auslastung sowie die Platten-IO-Leistung und speichert die grafische Darstellung in dem Ordner /var/log/Bootchart/. Hier werden alle Protokolle eindeutig bezeichnet und im PNG-Format abgespeichert.

Abbildung 16.3 Die Abbildung zeigt eine Boot-Chart-Analyse eines Ubuntu GNU/Linux 7.10, das mit Upstart hochfährt. Der Beispielrechner benötigt 19 Sekunden vom Starten des Kernels bis zum grafischen Login-Manager.

Wenn für Ihre Distribution bootchart nicht in den Paketquellen ist, können Sie dieses praktische Tool auch von der Seite www.bootchart.org herunterladen. Nach der Installation muss der Start des Programms noch in der Kernel-Kommandozeile eingetragen werden. Dies sieht für das normale init beispielsweise folgendermaßen aus:

/boot/grub/menu.lst 
[...] 
title Ubuntu (2.6.10) – bootchart 
    root (hd0,1) 
    kernel /vmlinuz-2.6.10 ro root=/dev/hda1 init=/sbin/bootchartd 
    initrd /initrd-2.6.10.img

Wenn Sie Upstart parallel installiert haben, fügen Sie zu der betreffenden Zeile die Angabe

bootchart_init=/opt/upstart/sbin/init

hinzu.

Abbildung 16.4 In der Grub-Konfigurationsdatei können Sie bestimmen, wie gesprächig Linux sich beim Starten gibt. Entfernen Sie den Parameter quiet splash aus der Kernel-Kommandozeile, wenn Sie eine detaillierte Anzeige wünschen.

Jobs

Die einzelnen Skripte, die beim Eintreffen eines Events ausgeführt werden sollen, werden von Upstart als Jobs bezeichnet. Diese Skripte werden im Verzeichnis /etc/event.d gesammelt (siehe Abbildung). Wie bei dem init-Konzept wird auch bei Upstart das Programm /sbin/init als erster Prozess vom Kernel gestartet. Die bekannte Datei /etc/inittab gibt es bei Upstart nicht mehr. Stattdessen werden die Jobs aus dem Verzeichnis /etc/event.d vom Upstart-Init gelesen.

Abbildung 16.5 Upstart-Events

Viele dieser Skripte sind in einem Kompatibilitätsmodus geschrieben. So werden Sie bei vielen Job-Skripten, beispielsweise einem typischen Runlevel-Skript, zurzeit feststellen, dass sie nichts anderes tun, als das entsprechende rc-Skript aufzurufen.

Abbildung 16.6 Kompatibilitätsscript vom rc1-Skript, das das System in den ersten Runlevel startet. Die Synthax ähnelt der Shell-Programmierung.

Das Skript aus Abbildung rc1.png ähnelt der normalen Shell-Programmierung und wird gestartet, wenn das System in den ersten Runlevel startet (start on runlevel 1, Zeile 5). Sobald dieser Runlevel verlassen wird, wird das Skript derart gestartet, dass alle gestarteten Tasks beendet werden (stop on runlevel [!1], Zeile 7).

Die Ausgabe des Skripts läuft über /dev/console (console output, Zeile 9), anstatt sie standardmäßig nach /dev/null zu leiten und damit zu ignorieren.

Mit den Befehlen script und end script (Zeile 10 und 19) wird das eigentliche Skript begrenzt. Innerhalb dieser Grenzen werden alle enthaltenen Zeilen durch die Shell /bin/sh ausgeführt; es wird der Runlevel gewechselt (Zeile 14) und der alte Runlevel über PREVLEVEL neu gesetzt (Zeile 13).

Zum Schluss wird der exec-Befehl ausgeführt (Zeile 18). Dieser ruft das /etc/init.d/rcSkript mit dem Parameter 1 auf (erster Runlevel). Damit sind alle Schritte abgearbeitet, und der Job ist erledigt.

Eine komplexere Semantik mit der Berücksichtigung von Vorbedingungen wird durch zusätzliche Befehle wie pre-start/end script und post-stop/end script formuliert. Weiterhin können logische Verknüpfungen erstellt und den Skripten Parameter übergeben werden. Wenn mehrere Dienste voneinander abhängig sind, können die Ereignisse start on bzw. stop on in Form von stopped name bzw. started name definiert werden.

Abbildung 16.7 Dieser Job startet den Start des Terminal-Emulators getty für die Textkonsole 1.

Beispielsweise erreichen Sie durch folgende Zeilen, dass das Skript erst dann ausgeführt wird, wenn rcS gestoppt ist:

@l:# /etc/event.d/rc-default 
start on stopped rcS 
script 
... 
end script

Um die Ereignisorientierung zu verstehen, sehen wir uns die Konfigurationsdatei /etc/event.d/tty1 an (siehe Abbildung). Dieser Job ist für den Start des Terminal-Emulators getty für die Textkonsole 1 zuständig. Hier sieht man, dass die exec-Anweisung (Zeile 16) erst dann ausgeführt wird, wenn eines der vorher mit start on definierten Ereignisse eintritt (Zeile 6-9). Analog wird getty wieder beendet, sobald ein Ereignis mit stop on eintritt (Zeile 11–13). Wenn das Programm ungeplant beendet wird, bewirkt das respawn einen Neustart von getty (Zeile 15).

Kompatibilität

Zurzeit werden lediglich die Terminal-Emulatoren der Textkonsolen von Upstart gestartet. Alle anderen Aufgaben werden durch das Kompatibilitätsskript /etc/init.d/rc erledigt. Dieses Skript wird durch die Upstart-Konfigurationsdateien rc0 bis rc6 sowie rcS gestartet und funktioniert wie gehabt. Das heißt, es führt alle Start- und Stopp-Skripte in den Ordnern /etc/rc0...6, S aus. Mittelfristig werden diese Verzeichnisse aber verschwinden, und /etc/event.d wird alle Aufgaben übernehmen.

Wie Sie gesehen haben, benutzt Upstart einige neue Kommandos, um Prozesse zu starten und zu stoppen, anstehende Ereignisse anzuzeigen und zu überwachen. Dienste, die über die Kompatibilitätsschicht gestartet werden, funktionieren weiterhin nach der Debian-Methode, d. h. über invoke.rc, update-rc.d usw.

Das erste Ereignis beim Systemstart ist startup, das durch /sbin/init ausgelöst wird. Nach Ausführen der Skripte in rcS und rc-default wird der Runlevel 2 aktiviert. Daraufhin wird das Skript aus rc2 und die exec-Anweisungen aus tty1 bis tty6 ausgeführt.

Die folgende Tabelle zeigt eine Übersicht der in Ubuntu 9.04 vorhandenen Skripte im Verzeichnis /etc/event.d (die zweite Spalte gibt lediglich die start-on-Ereignisse an).

Im Übrigen befinden sich im Ordner /var/log/boot zahlreiche Log-Informationen. Generell gehen die Ausgaben der Upstart-Skripte an den in Upstart enthaltenen logd, der die Informationen im genannten Verzeichnis speichert.

Kommandos

Wenn im Verzeichnis /etc/event.d eine entsprechende Konfigurationsdatei liegt, starten bzw. beenden die Befehle start bzw. stop einen Prozess. Der Befehl status gibt den aktuellen Zustand des Prozesses an.

Administrative Aufgaben erledigen Sie mit initctl (man initctl). Mit initctl list verschaffen Sie sich einen Überblick über alle laufenden Prozesse (siehe Abbildung).

Wenn Sie eigene Skripte testen möchten, können Sie durch Eingabe von

initctl emit 'name'

ein Ereignis mit dem Namen name erzeugen.

Abbildung 16.8 Mit start bzw. stop können Sie Prozesse stoppen.

Upstart kennt aus Kompatibilitätsgründen zum Init-V-System auch Runlevel. Diese sind allerdings als Ereignisse mit den Namen runlevel n definiert. Das Kommando runlevel zeigt Ihnen den aktuellen Runlevel an. Einen neuen Runlevel aktivieren Sie mit telinit n.

Abbildung 16.9 Mit dem Befehl initctl verschaffen Sie sich Überblick.

Fazit

Auch Upstart ist also kein Wundermittel; Boot-Zeiten wie bei Spielekonsolen sind auch mit diesem Ansatz reine Fantasie. Die Unterschiede zum bisherigen init sind marginal, aber es ist nicht zu bezweifeln, dass Upstart vom Konzept her der bisherigen Technik überlegen ist. Mit etwas Optimismus lässt sich erahnen, dass seine Vorteile in den nächsten Jahren wesentlich stärker zutage treten werden. Auch wenn Upstart nur einige Sekunden Zeitvorteil erarbeitet, schont es hier doch die Nerven der Anwender unserer modernen Betriebssysteme. Wer Upstart nur auf das Booten des PCs beschränkt, tut dem Projekt unrecht. Upstart ist auf dem guten Weg dahin, in zukünftigen Versionen immer mehr die Aufgabe eines zentralen Service-Daemons zu übernehmen.

Ihr Kommentar