Der Upstart ist eine SysVinit-Alternative.
http://www.initng.org http://upstart.ubuntu.com
alle auflisten:
# initctl list
Jobcontrol:
# [start|stop|status]
Events:
# initctl [emit|events]
hier liegen die Startup-Scripte (nicht ausführbare Dateien mit der Endung ".conf"):
# ls -l /etc/init/
ein Startup-Script enthält drei Ausführungs-Zeiten:
Stanzas:
die Events:
In Ubuntu sendet das Script /etc/network/if-up.d/upstart die Event's:
initctl emit -n net-device-up \
"IFACE=$IFACE" \
"LOGICAL=$LOGICAL" \
"ADDRFAM=$ADDRFAM" \
"METHOD=$METHOD"
Diese Event's werden so verwendet:
start on started net-device-up IFACE=eth0
Die folgende Zeile besagt, das ein "start" ausgeführt werden soll, wenn der Event "started" vom Job "networking" gesendet wurde:
start on started networking
Der "Job" hat in aller Regel den selben Namen wie die upstart-Konfigurationsdatei ohne Endung. Also heißt zur Datei "/etc/init/networking.conf" der entsprechende Job "networking".
Wenn man sich mit
# initctl list
die Job's ansieht, wird man aber feststellen müssen, dass der Job "networking" immer auf "stop/waiting" steht!
Demzufolge kann man den Job "networking" nicht als Event verwenden.
Alternativ kann man auch die Event's des UpStart-Script's "/etc/init/network-interface.conf" verwenden:
start on started network-interface INTERFACE=eth0
Ein einfaches Upstart-Script könnte so aussehen:
# vi /etc/init/test.conf
description "Beschreibung dieses Dienstes"
author "ich"
start on (runlevel [2345]
and net-device-up IFACE=eth0)
console output
script
Script-Zeile
Script-Zeile
Script-Zeile
Script-Zeile
end script
Die Ladezeit des Linux-Kernels macht nur noch einen kleinen Teil der Zeit aus, die man bei jedem Systemstart auf den Login-Prompt wartet. Die meiste Zeit wartet der Rechner darauf, dass das von Unix System V abstammende init durch die verschiedenen Runlevel wechselt und dabei unzählige Init-Skripte nacheinander abarbeitet. Bei Ubuntu und Fedora hat Upstart schon länger das traditionelle SysV-Init abgelöst.
…
Sowohl Upstart als auch SysV-Init werden vom Kernel als erster Prozess mit der ID 1 gestartet, sobald dieser gebootet und etwaige Boot-Skripte aus der Initial Ramdisk (Initrd) abgearbeitet hat. Bei SysV-Init ist die Datei /etc/inittab der Dreh- und Angelpunkt für die Systeminitialisierung. Hier findet SysV-Init den Default-Runlevel, den Namen des ersten Initialisierungs-Skripts sowie die Kommandos zur Initialisierung der jeweiligen Runlevel. Bei der Initialisierung der Runlevel werden dann die im jeweiligen Runlevel-Verzeichnis (etwa /etc/rc5.d) verlinkten Init-Skripte nacheinander gestartet.
…
Upstart hingegen arbeitet Event-orientiert mit sogenannten Jobs, wobei jede Job-Datei im Verzeichnis /etc/init für den Start eines Dienstes oder einen bestimmten Teil der Systeminitialisierung zuständig ist. Eine feste Reihenfolge gibt es nicht, stattdessen gibt jeder Job an, auf welche Events er reagieren möchte. Tritt ein Event auf, startet Upstart parallel alle Jobs, die auf dieses Event gewartet haben.
…
Will man einen Job außer der Reihe starten oder anhalten, so kann man dies per
# initctl start Jobname
respektive
# initctl stop Jobname
tun. Welches Programm der Job aufruft, steht hinter exec. Ein großer Unterschied zwischen Upstart und SysV-Init ist, dass in den Init-Skripten Dienste immer im Hintergrund starten, weil sie sonst Init blockieren. Upstart hingegen erwartet, dass der hinter exec genannte Prozess im Vordergrund läuft – denn nur so lange dieser Prozess läuft, betrachtet Upstart den Job als laufend (running). Endet ein mit exec gestarteter Prozess, so endet für Upstart auch der Job und wartet darauf, dass wieder ein passendes Event auftritt (waiting). Dabei merkt sich Upstart den Zustand jedes Jobs, der in /etc/init gelistet ist. Diese Informationen können Sie mit den Befehlen
# initctl list
und
# initctl status Jobname
abrufen.
…
Das Event-gesteuerte Konzept von Upstart unterscheidet sich grundlegend von dem von SysV-Init, wo die Init-Skripte stur der lexikalischen Reihenfolge im jeweiligen Runlevel-Verzeichnis nach aufgerufen werden. Das macht Upstart sehr viel flexibler: Besteht zum Beispiel beim Start des Mail-Daemons (MTA) noch keine Netzwerkverbindung, muss man bei SysV-Init den Timeout abwarten, bevor das System weiter bootet. Bei Upstart hingegen würde der MTA erst dann gestartet, wenn die Netzwerkverbindung steht: Als Start-Event würde beim MTA-Job das Event network up konfiguriert, das der für die Netzwerkeinrichtung zuständige Dienst erst nach erfolgreicher Netzwerkkonfiguration auslöst – auf einem Notebook unterwegs im Zweifel also gar nicht.
Dadurch, dass es keine feste Startreihenfolge der Jobs gibt, kann ein System mit Upstart schneller booten als eines mit SysV-Init. Hinzu kommt, dass durchaus mehrere Jobs gleichzeitig abgearbeitet, also Initialisierungsaufgaben parallelisiert werden – auch dadurch lässt sich potenziell Zeit sparen.
…
Beim Anhalten eines Jobs kümmert sich Upstart lediglich um den per exec im Vordergrund gestarteten Prozess: Er sendet ihm das Terminate-Signal (SIGTERM) und erwartet, dass er sich selbst beendet. Widerspruch duldet Upstart nicht – beendet sich der Prozess nicht, wird er wenige Sekunden später mittels Kill-Signal (SIGKILL) hart abgebrochen. Ein einmal ausgelöstes Stop-Event kann ein Dienst also weder blockieren noch verzögern oder gar rückgängig machen.
Mit Hilfe der Schlüsselwörter pre-stop und post-stop lassen sich Befehle angeben, die Upstart vor und nach dem Beenden des Dienstes ausführen soll. Dies ist für etwaige Aufräumarbeiten interessant. Hier ein Beispiel:
# post-stop exec rm -f /var/run/tserv.pid
Zeitlicher Ablauf eines Upstart-Jobs Vergrößern Zusätzlich gibt es noch die Schlüsselwörter pre-start und post-start, mit denen Befehle unmittelbar vor und nach dem Start eines Dienstes ausgeführt werden können, etwa um notwendige Verzeichnisse anzulegen oder nach dem Start des Dienstes bestimmte Systemeinstellungen anzupassen. Da exec erwartet, dass der Dienst im Vordergrund startet, kann Upstart mit der Ausführung von post-start nicht warten, bis der Dienst beendet wurde. Deshalb führt Upstart post-start parallel mit dem Start des Dienstes aus.
…
In den bisherigen Beispielen wurden Befehle stets unmittelbar per exec aufgerufen. Anstelle von exec kann jedoch auch ein Befehlsblock gesetzt werden, der von den Schlüsselwörtern script und end script eingeschlossen wird:
pre-start script
if [ ! -e /var/run/tserv ]; then
mkdir -p /var/run/tserv
fi
end script
Ersetzt man den exec-Aufruf für den Start des Dienstprogramms durch einen Befehlsblock, so muss man beachten, dass Befehle, die hinter dem Aufruf des Dienstes stehen, nur dann ausgeführt werden, wenn sich der Dienst unmittelbar beim Aufruf beendet. Wird der Dienst später mittels Terminate-Signal von Upstart regulär beendet, geschieht dies nicht.