© sxc.hu/Dimitris Petridis

Lahme Bootzeiten sind lästig. Da hilft auch kein 'Linux läuft über Monate stabil', gefragt sind Schnellstarter, die nach dem Anschalten oder dem per Kernel-Update erzwungenen Reboot nicht erst minutenlang bummeln. Ubuntu entwickelt gerade einen viel versprechenden Ansatz.

Upstart soll den Bootvorgang umkrempeln. Das ambitionierte Projekt [1] aus dem Hause Ubuntu führt dazu einen generischen Init-Daemon ein, der von vielen Entwicklungen moderner Linux-Systeme profitiert. Geschickt vermeidet Upstart unnötige Wartephasen, lässt Startskripte parallel arbeiten und reduziert die Bootzeit auf das Nötige. Längerfristig soll Upstart als generische Schnittstelle für System-Hintergrunddienste auch den At-Daemon, Cron und weitere ablösen. Erste Schritte in Richtung fliegender Start sind im gerade erschienen Ubuntu 6.10 (Edgy Eft) schon erkennbar.

An dem lahmen Bootvorgang haben sich schon viele Projekte versucht [2]. Kein Wunder, denn das minutenlange Booten ihrer ansonsten hochgezüchteten Maschine ärgert die Benutzer. Das gefühlte Missverhältnis ist groß: Obwohl das Herz der Maschine mit 3 Gigahertz pulsiert und die Festplatte rast, bringt die Kiste für Minuten nur einen öden Splashscreen zustande.

Suse Linux 10.1 zum Beispiel braucht auf einem Thinkpad X41 eine Minute, bis sich der Benutzer einloggen darf. Vieles liegt am in die Jahre gekommenen Bootkonzept des Unix-System-V-Inits (siehe Kasten “Sys-V-Init”). Das ehemals revolutionäre Konzept mutierte zum Bremsklotz. Es gibt zwar etliche Tricks, die dem Start etwas auf die Sprünge helfen, als wirkliche Lösungen taugen sie jedoch nicht. Zudem sind viele Turbo-Lader für den normal erfahrenen Linux-Anwender undurchschaubar. Upstart versucht daher eine komplett eigene Herangehensweise, um dem Bootvorgang neuen Schwung zu verleihen.

Sys-V-Init

In frühen Unix-Versionen war ein einfaches Shellskript dafür zuständig, die Maschine zu konfigurieren und Dienste zu starten. Das Konzept beispielsweise von »/etc/rc« aus der BSD-Familie war bestechend simpel, hatte jedoch einen gravierenden Nachteil: Um Drittanbieter-Software oder eigene Erweiterungen einzubinden, waren Änderungen am Shellskript nötig. Dessen Code zu modifizieren ist aber recht gefährlich, bei Fehlern bleibt schnell ein nicht mehr bootfähiges System zurück. Oft genügt zum Start eines Dienstes kein simples Kommando ohne Parameter, sondern es sind Zusatzinformationen nötig, die je nach Umgebung variieren. So kann beispielsweise der ISC-DHCP-Server auf bestimmten Ethernet-Interfaces statt auf allen Ports lauschen. Damit der Admin für solche Änderungen nicht ebenfalls direkt das Startskript bearbeiten muss, gibt es oft eine Konfigurationsdatei, die das Skript einliest. Das erlaubt Updates der Startskripte, ohne die lokale Konfiguration zu gefährden. Das Sys-V-Init verwendet gegenüber BSD einen deutlich flexibleren, aber auch komplexeren Ansatz. Es führt mehrere Runlevels ein, die einen bestimmten Zustand der Maschine definieren, abgeleitet von den dann laufenden Prozessen. Es sind acht Runlevels möglich, aber nicht zwingend in allen Systemen auch belegt. Drei Runlevels haben fest definierte Aufgaben: Halt (0), Single User Mode (1) und Reboot (6). Welche Runlevels festgelegt sind und in welchen Runlevels ein System beim Booten startet, steht in der Datei »/etc/inittab« (siehe Abbildung 1). Das Sys-V-Konzept geht davon aus, dass sich das System standardmäßig in wenigen definierten Zuständen befindet, etwa Betrieb ohne oder mit Netzwerk und mit X11. Einen Wechsel zwischen diesen Runlevels triggert der Sysadmin mit »init Runlevel«. Ein weiterer Vorteil liegt in den separierten Skripten für jeden Dienst oder Konfigurationsvorgang. So ist es möglich, durch den Aufruf von beispielsweise »/etc/init.d/dhcpd restart« einfach nur den DHCP-Server neu zu starten. Auch die Idee, per Symlink-Sammlung die Auswahl und Reihenfolge der in einem Runlevel nötigen Skripte zu bestimmen, überzeugte. Abbildung 1: Diese typische »inittab« definiert die Runlevels 0 bis 6 und bestimmt Runlevel 5 als Default. Beim Drücken der Tastenkombination [Ctr]+[Alt]+[Delete] löst Init einen Reboot aus.

Am Anfang steht Init

Auf den meisten Unix-artigen Systemen ruft der Kernel Init auf und gibt ihm die Prozess-ID 1. Der Ablauf ist fest einkompiliert, unter Linux in »/usr/src/linux/init/main.c«. Init startet im Userspace alle weiteren Prozesse und initialisiert die Maschine. Der Prozess und seine Hilfsskripte laden Kernelmodule, prüfen und mounten die Dateisysteme, richten das Netzwerk ein, starten Serverdienste und rufen den grafischen Login-Manager auf. Dabei muss Init die Dienste in einer vernünftigen Reihenfolge anstoßen. Der Abgleich der Systemzeit mit einem Zeitserver im Netz ist erst sinnvoll, wenn die Maschine erreichbar ist. Dazu muss die Netzwerk-Hardware initialisiert und mindestens ein Netzwerk-Interface mit Außenzugang eingerichtet sein.

Die Zahl der Dienste und der im Hintergrund lauernden Agenten hat im Laufe der Jahre zugenommen und den Init-Prozess schwerfällig gemacht. Gerade der Desktop-Einsatz, wie ihn Ubuntu anstrebt, erfordert eine recht dynamische Systemkonfiguration, Mobilgeräte machen dem Sys-V-Init das Leben zusätzlich schwer. Da hängen Dienste von einer funktionierenden Netzwerkverbindung ab, die über wechselnde Devices erst ad hoc aufgebaut wird.

Für diese Zwecke gibt es Tools: »acpid« und »apmd« fürs Powermanagement, HAL-Device-Manager fürs dynamische Einbinden von Laufwerken oder den Resource-Manager für die dynamische Zuweisung der Device-Rechte an den lokal angemeldeten User. Jedes dieser Systeme implementiert seine eigene Konfigurationslogik, die Admins lernen müssen, um eine bestimmte Aufgabe zum richtigen Zeitpunkt erledigen zu lassen.

Nicht alle Prozesse und Dienste sind mit dem Start und Stopp einer Maschine verknüpft. Es gibt spezialisierte Services wie Cron und den At-Daemon, die Prozesse zu bestimmten Zeitpunkten starten. Bisher sind sie in keiner Weise mit dem Runlevel-System verbunden, obwohl ihnen eine ähnliche Logik unterliegt. Auch das will Upstart ändern [4].

Bevor sich die Entwickler von Ubuntu entschieden ein neues System zu entwickeln, haben sie die damals bekannten Sys-V-Alternativen [2] gesichtet. Keines der in Frage kommenden Konzepte erfüllte ihre Erwartungen oder war unter einer akzeptablen Lizenz verfügbar.

Bei ihrem eigenen Entwurf entschieden sich die Entwickler gegen einen ziel- und für einen ereignisorientierten Ansatz. Zielorientiert bedeutet, zu definieren, welche Dienste am Ende des Startvorgangs laufen sollen (KDM, SSH-Daemon …). Für jeden Dienst sind seine Abhängigkeiten zu definieren, aus denen das Init-System eine sinnvolle Startreihenfolge ableitet. Diesen Weg verfolgen Gentoo mit »depend« (siehe Kasten “Gentoo”), aber auch Suse mit einer abgewandelten Version des Sys-V-Init (siehe Kasten “Suse”).

Das Gegenkonzept dazu sind Events. Statt Abhängigkeiten zu formulieren, um die sich ein Skript bei seinem Start womöglich selbst kümmert, läuft ein Skript im Event-System erst dann, wenn alle Vorbedingungen erfüllt sind. Sinnvoll wäre es etwa, einen NFS-Client erst dann aufzurufen, wenn der eingetragene NFS-Server erreichbar ist. Das System, für das sich Ubuntu entschieden hat, versteht auch komplexere Vorbedingungen, etwa “Netzwerkkonfiguration erfolgreich abgeschlossen” und “Apache läuft” oder künftig “USB-Stick angestöpselt”.

#!/sbin/runscript
opts="depend start stop restart"
depend() {
  # Abhängigkeiten und Voraussetzungen
}
start() {
  # Kommandos zum Start eines Dienstes
  # inklusive Vorbereitungen
}
stop() {
  # Kommandos zum Anhalten eines Dienstes
  # plus Aufräumaktionen
}
restart() {
  # Restarten eines Dienstes
}

case $(sed 's/#.*//' /etc/syslog-ng/U
syslog-ng.conf) in
  *source*tcp*|*source*udp*|*destinationU
*tcp*|*destination*udp*)
  need net ;;
esac

### BEGIN INIT INFO
# Provides: nbd-server
# Required-Start: $network
# Should-Start: $syslog
# Required-Stop:
# Default-Start:  3 5
# Default-Stop:   0 1 2 6
# Description:    Start Network Blockdevice Daemon
### END INIT INFO

Ereignis-Horizont

Events sind im Grunde einfache Zeichenketten. Die möglichen Ausprägungen teilen die Upstart-Autoren in drei Klassen:

• Einfache Edge-Events, etwa “System startet” oder “Benutzer hat einen Knopf gedrückt”.
• Level-Events erhalten zusätzlich einen Parameter, etwa den Zustand eines Netzwerk-Interface. Dienste und Tasks sollen bei jedem Level-Event laufen oder nur, wenn der Parameter einen bestimmten Wert erreicht hat.
• Temporale Events, die nach einer bestimmten Zeit oder zu einem definierten Zeitpunkt eintreten.

Die Entwickler hielten sich an den guten Ton der Open-Source-Szene: Release early, release often. So erschien der Code frühzeitig, die Programmierer haben mit Edgy Eft an einem laufenden System selbstbewusst demonstriert, wie weit sie sind. Sie hoffen auf Feedback von Entwicklern anderer Distributionen. Daher kann sich die Upstart-Spezifikation noch ändern. Die hier beschriebenen Beispiele beziehen sich auf die Anfang Dezember aktuelle Version 0.3.

Diese Version schafft es schon, den vorhandenen Init-Prozess zu ersetzen. Noch sind aber bei weitem nicht alle Startskripte auf den Event-Mechanismus umgestellt. Die temporalen Events beherrscht Upstart ebenfalls noch nicht. Geplant ist, als Eventquellen auch andere Programme zu nutzen, etwa Udev und den ACPI- oder APM-Daemon.

Zwischenstand

Auf dem aktuellen Ubuntu geht der Systemstart dennoch schon recht zügig vonstatten. In der Standardeinstellung ist davon kaum etwas zu sehen – die Aufteilung des Boot-Splash in Fortschrittsbalken und OS-Logo verbirgt jede verwertbare Information. Aber auch ohne bunten Splash (das Token »splash« aus der Kernel-Kommandozeile in Grub löschen) halten sich die Meldungen in Grenzen. Wer mehr sehen möchte, entfernt »quiet« (Abbildung 2).

Abbildung 2: Die Grub-Konfiguration bestimmt, wie gesprächig sich Ubuntu beim Booten gibt. Ohne »splash« (blau) gibt’s die klassische Textkonsole, ohne »quiet« eine ganze Reihe zusätzlicher Ausgaben. An gleicher Stelle (grau) ist die gewünschte Init-Variante einzutragen, hier »/opt/upstart/sbin/init«.

Auch unter der Haube bleiben die Änderungen zunächst verborgen. Erst der Aufruf von »man init« oder »man telinit« weist darauf hin, dass im Runlevelsystem ein neuer Motor werkelt. Ein weiterer sichtbarer Unterschied liegt im Fehlen der Datei »/etc/inittab«. Dass »/etc/init.d« mit seinen Startskripten noch vorhanden ist, liegt am derzeit verwendeten Kompatibilitätsmodus von Upstart. Mittelfristig wird »/etc/event.d« alle Aufgabendefinitionen übernehmen. Das sind einfache, nicht ausführbare Textdateien der in Listing 1 gezeigten Art. Das Beispiel macht sich die Arbeit leicht und ruft schlicht die alten Startskripte für Runlevel 2 auf (Zeile 20).

Zeile 5 zeigt, dass das Skript laufen soll, wenn der Event »runlevel-2« auftritt. Es endet, falls die Events »shutdown« oder »runlevel-3« bis »runlevel-5« eintreten (Zeilen 7 bis 10). Künftig soll eine komplexere Semantik auch Vorbedingungen mit logischen Verknüpfungen erlauben sowie auf Wunsch den Event-Skripten Parameter übergeben. Diese Dateien entsprechen den Einträgen in der alten »/etc/inittab«. Deshalb sind beim Edgy Eft neben dem gezeigten »rc2« die im oberen Teil von Abbildung 3 zu sehenden Dateien vorhanden.

Abbildung 3: Bei Edgy Eft liegen im Verzeichnis »/etc/event.d« Dateien, die Jobs für die typischen Events der alten Inittab definieren. Deshalb finden sich dort ein »control-alt-delete« ebenso wie die verschiedenen Runlevels und die zu startenden Konsolen-Gettys.

Upstart-konforme Jobs

Es gibt zwei Möglichkeiten, eigene Jobs zu definieren. Die einfache Methode benutzt »exec /Pfad/Programm -O –Option Parameter«. Das funktioniert wie von der Shell gewohnt. Upstart bedient sich auch tatsächlich der Hilfe einer Shell, sobald es auf Quotierungen »””« oder »$« stößt. Wenn die Jobdefinition etwas mehr als einen einfachen Kommandoaufruf enthält, darf ein Shellskript zwischen den beiden Token »script« und »end script« stecken (Listing 1, Zeilen 12 bis 21).

Von dieser Skriptform gibt es die beiden Abwandlungen »start script« und »stop script«. Das Startskript dient dazu, alles Notwendige für einen bestimmten Dienst vorzubereiten, beispielsweise Verzeichnisse anlegen oder Zugriffsrechte überprüfen. Das Stoppskript räumt nach Ende des Dienstes wieder auf.

01 # /etc/event.d/rc2
02 # Runlevel-2-Kompatibilitätsskript für Upstart
03 # Dieser Job führt die alten Sys-V-Skripte aus.
04 
05 start on runlevel-2
06 
07 stop on shutdown
08 stop on runlevel-3
09 stop on runlevel-4
10 stop on runlevel-5
11 
12 script
13     set $(runlevel --set 2 || true)
14     if [ "$1" != "unknown" ]; then
15         PREVLEVEL=$1
16         RUNLEVEL=$2
17         export PREVLEVEL RUNLEVEL
18     fi
19 
20     exec /etc/init.d/rc 2
21 end script

Ein simpler Serverdienst eignet sich bestens als Beispiel für eigene Upstart-Skripte. Er braucht gar nichts zu tun, außer dauerhaft zu laufen. Die folgenden Erklärungen gelten für einen Zweizeiler in »/usr/local/bin/simpleserver.sh«:

#/bin/sh
while true ; do sleep 1 ; done

Das zum Dienst passende Event-Skript erhält den Namen »/etc/event.d/simple-server«. Soll der Dienst nur auf einen manuellen Aufruf hin laufen, genügt eine einzelne Zeile im Event-Skript, die den Server startet:

exec /usr/local/bin/simpleserver.sh

Für Start und Stopp von Diensten – inklusive des eben definierten Service – sind weiterhin die Kommandos »start« und »stop« zuständig. Dazu gesellt sich der »status«-Aufruf. Ein schlichtes »start simple-server« bringt den neuen Dienst in Aktion. Ob das Kommando erfolgreich war, verraten »initctl list« oder »status simple-server«. Mit »stop simple-server« endet der Dienst wieder (Listing 2).

01 root@EdgyEft:~# start simple-server
02 simple-server (start) running, process 6507 active
03 root@EdgyEft:~# stop simple-server
04 simple-server (stop) running, process 6507 killed
05 root@EdgyEft:~# status simple-server
06 simple-server (stop) waiting
07 root@EdgyEft:~# start simple-server
08 simple-server (start) running, process 6517 active
09 root@EdgyEft:~# status simple-server
10 simple-server (start) running, process 6517 active

Log-Suche

Wenn alles funktioniert, interessieren sich die wenigsten Anwender für Systemmeldungen. Gerade nach tiefen Eingriffen ins System erweisen sich Log-Informationen aber als sehr hilfreich. Wer sie nicht wie oben beschrieben schon beim Booten auf den Schirm bringt, kann nachträglich danach fahnden. Generell gehen die Ausgaben der Upstart-Skripte an den im Paket enthaltenen »logd«, der seinerseits die Informationen in »/var/log/boot« hinterlässt. Eine weitere Quelle für Debugging-Output ist der »initctl list«-Aufruf (Abbildung 5).

Abbildung 5: Das Kommando »initctl list« gibt einen Überblick über den Systemstatus. Im Kompatibilitätsmodus lässt nur der selbst gestrickte »simple-server« ahnen, dass an dieser Stelle künftig Services statt Runlevels auftauchen.

Da Ubuntu auf Debian basiert, gibt es berechtigte Hoffnung, dank der Neuerungen des einen auch den anderen zu beschleunigen. Wer es riskieren möchte, hat die Wahl, das bestehende Sys-V-Init komplett durch Upstart zu ersetzen oder beide Init-Varianten parallel zu installieren und sie fallweise zu nutzen.

Debian aufbohren

In Debian Unstable ist der Schritt für Variante 1 (Upstart als Komplettersatz) recht einfach, da die Entwickler der Distribution bereits die notwendige Vorarbeit geleistet haben: Sie trennten das Paket »sysvinit-utils« vom Paket »sysvinit«. Damit ist es problemlos möglich, »sysvinit« durch Upstart zu ersetzen und die alten Skripte dennoch zu behalten. Upstart steht als Paket in Debians Experimental-Repository [3] zur Verfügung. Um es zu nutzen, lautet der Eintrag in »/etc/apt/sources.list«:

deb http://ftp.de.debian.org/debian/ experimental main

Anschließend entfernt »apt-get install upstart upstart-compat-sysv« das alte »sysvinit«-Paket. Da »sysvinit« jedoch als »required« markiert ist, wartet die Paketverwaltung, bis der Benutzer den Satz »Yes, do as I say!« abtippt. Die nächste Falle lauert beim Update: Auch ein »apt-get dist-upgrade« wirft die neu installierten Upstart-Pakete wieder weg und holt das alte »sysvinit«-Paket hervor. Danach stehen wieder die manuelle Deinstallation von »sysvinit« und Installation von Upstart an.

Selbst ist der Admin

Wer Upstart selbst übersetzt, sollte zuvor das »sysvinit«-Paket entfernen. Andernfalls überschreibt »make install« die alten Binaries und der Paketmanager bemerkt entweder nichts von der Neuerung oder – schlimmer – hält das System für korrumpiert. Upstart ist schnell aus den Quellen [1] kompiliert und installiert:

./configure --prefix=/usr --exec-prefix=/ --sysconfdir=/etc
make
make install

Anschließend verlangt das System nach passenden Init-Skripten. Für den Anfang empfiehlt es sich, den Tarball »example-jobs-2.tar.gz« von [1] aus dem Verzeichnis »/download« nach »/etc/event.d« zu entpacken.

Wer vermeiden will, dass ein erfolgloser Upstart-Installationsversuch ihm auch noch das funktionierende System-V-Init-System ruiniert, kann Upstart nebenan einrichten. Dafür verfährt er wie zuvor erklärt, behält aber das »sysvinit«-Paket und sorgt dafür, dass das neue Init in »/opt/upstart« landet:

./configure --prefix=/opt/upstart --sysconfdir=/etc --enable-compat

Diese Variante erfordert eine Anpassung der nach »/etc/event.d« gekippten Skripte. Es reicht aus, in den Dateien »rc-default« und »rcS-sulogin« hinter der Zeile »script« folgende Zeile einzufügen:

export PATH=/opt/upstart/sbin:$PATH

Weil das Upstart-Verzeichnis nun am Anfang des Suchpfads steht, nutzen alle Skripte das neue »telinit«-Kommando.

Ohne weitere Eingriffe bootet im Parallelbetrieb immer noch der Sys-V-Init. Beim Booten kann der Benutzer dem Kernel aber sagen, dass er ein anderes Programm statt des gewohnten Init wünscht. Das erledigt folgender Parameter an der Kernel-Kommandozeile: »init=/opt/upstart/sbin/init«. Für einfache Tests ist es am schnellsten, den Parameter am Prompt des Bootloaders anzugeben oder ihn als festen Menü-Eintrag in die Bootloader-Konfigurationsdatei aufzunehmen (Listing 3a, Zeile 5).

01 # /boot/grub/menu.lst
02 [...]
03 title    Ubuntu, kernel 2.6.17-10-generic
04 root     (hd0,0)
05 kernel   /boot/vmlinuz-2.6.17-10-generic root=/dev/hdb1 ro quiet splash init=/opt/upstart/sbin/init
06 initrd   /boot/initrd.img-2.6.17-10-generic
07 boot
08 [...]

Analyse

Um den Startvorgang des neuen Systems mit dem alten zu vergleichen, bietet sich Bootchart an [4]. Dieses praktische Messwerkzeug protokolliert während des Bootvorgangs die CPU-Auslastung und Platten-IO-Leistung, um sie später in eine schöne Grafik zu verwandeln. Damit alles klappt, muss das gleichnamige Paket installiert und in der Kernel-Kommandozeile eingetragen sein.

Der »bootchartd« fungiert dann als initialer Prozess, der das eigentliche »init« startet. In Grub sähe die entscheidende Zeile so aus, wie in Listing 3b gezeigt. Läuft Upstart im Parallelbetrieb neben dem klassischen Init, dann muss auch Bootchart davon wissen – die Kernelzeile wächst um »bootchart_init=/opt/upstart/sbin/init«.

Nun protokolliert Bootchart alle 0,2 Sekunden die interessanten Prozessdaten und legt beim Abschluss des Bootvorgangs die Informationen in »/var/log/bootchart.tgz« ab. Der Befehl »bootchart -f png« erzeugt daraus ein PNG-Bild, alternativ sind via »svg« oder »eps« auch Vektorgrafiken möglich.

01 # /boot/grub/menu.lst
02 [...]
03 kernel   /boot/vmlinuz-2.6.17-10-generic root=/dev/hdb1 ro quiet splash init=/sbin/bootchartd
04 [...]

Ein Vergleich der Grafik des Sys-V-Boots (Abbildung 4a) mit der von Upstart (Abbildung 4b) täuscht zunächst. Auf dem Testrechner meldet Bootchart, dass der klassische Sys-V-Init ganze 31 Sekunden braucht, während Upstart schon nach 23 Sekunden fertig ist. Eine Kontrollmessung mit der Stoppuhr zeigt aber, dass der tatsächliche Zeitgewinn nur 2 Sekunden beträgt. Bootchart täuscht sich, weil es mit der Zeitmessung aufhört, sobald KDM oder ein anderer Login-Manager läuft. Die Parallelausführung in Upstart zieht diesen Schritt nach vorne, bevor andere wichtige Startprozesse abgeschlossen sind.

Abbildung 4a: Diese Bootchart-Analyse zeigt ein Debian GNU/Linux, das mit herkömmlichem Init-Prozedere hochfährt. Das Werkzeug hat während des Bootvorgangs fünfmal pro Sekunden gemessen.

Abbildung 4b: Ersetzt Upstart den Sys-V-Init, dann ändert sich das Boot-Bild kaum, weil im Kompatibilitätsmodus die herkömmlichen Skripte laufen.

Wer jetzt wegen der eher bescheidenen Erfolge Upstart schon aufs Abstellgleis schieben will, tut dem Projekt aber Unrecht: Der Init-Nachfolger läuft derzeit noch komplett im Kompatibilitätsmodus. Echter Zeitgewinn ist erst dann zu erwarten, wenn die einzelnen Startskripte tatsächlich auf das neue System angepasst sind. So erwartet Ubuntu erst im Edgy-Nachfolger Feisty Fawn deutliche Fortschritte bei den Bootzeiten.

Flotte Aussichten

Die Zeiten, in denen ein Rechner in wenigen Sekunden betriebsbereit war, sind vorbei. Die kosmetischen Korrekturen, wie sie viele Distributionen als Beschleuniger einsetzen, helfen nicht wirklich. Nur neue Konzepte wie Upstart haben eine reelle Chance. Was davon jetzt schon mit dem aktuellen Ubuntu zu sehen ist, lässt für die Zukunft hoffen. Die Zahl der in ihrem Maschinenpark einsparbaren Minuten wird viele Administratoren davon überzeugen, sich mit Upstart zu beschäftigen.

Wenn auch Upstart nicht das “Einschalten und los”-Gefühl der Spielekonsolen erreicht, strapaziert es die Geduld des Anwenders doch etwas weniger. Voraussetzung sind jedoch solide Admin-Kenntnisse, ohne die eine laufende Linux-Maschine schnell zum Kandidaten für eine Neuinstallation mutiert.

Ein Blick in die Zukunft lässt vermuten, dass Upstart mehr als die Erneuerung des Bootprozesses anstrebt: Als ein zentraler Service-Daemon soll es Aufgaben übernehmen, die jetzt noch ein ganzer Zoo aus Tools verantwortet. Dazu gehört, Events zu bestimmten Zeitpunkten auszuführen, also Cron und At zu ersetzen. Zuerst muss Upstart aber beweisen, dass es den Bootprozess ordentlich organisiert – es scheint auf dem besten Wege. (fjl)

Abbildung 5: Das Kommando »initctl list« gibt einen Überblick über den Systemstatus. Im Kompatibilitätsmodus lässt nur der selbst gestrickte »simple-server« ahnen, dass an dieser Stelle künftig Services statt Runlevels auftauchen.