Captains Log

Eine der "großen Neuerungen" von Solaris 10 war sicherlich SVC, der "init.d-Ersatz". Die lieb gewonnen Runlevel-Scripte bringen in aktuellen Systemen eine Reihe von Nachteilen mit sich. So werden sie streng anhand ihrer nummerierten Reihenfolge ausgeführt, ohne dass Abhängigkeiten berücksichtigt werden.
Das bedeutet zum einen, dass kein Nutzen aus SMP-Systemen gezogen werden, weil immer ein Script nach dem anderen ausgeführt wird. Zum anderen muß ein nachfolgendes Script davon ausgehen, dass seine Vorgänger gestartet worden sind, es gibt vernünftige Möglichkeit, Fehler abzufangen.
Wenn also irgendwo ein Fehler aufgetreten ist bootet das System trotzdem weiter und es kommt zu einer ganzen Reihe Folgefehler. Im Ernstfall kann man kaum abschätzen in welchem Zustand ein System dann ist, und was man noch alles machen muß, nachdem der ursprüngliche Fehler behoben ist.
 
Mittlerweile sind eigentlich alle Unixe von den Runlevel-Scripten entweder abgekommen, oder haben Erweiterungen daran vorgenommen, so definieren z.B. BSDs und Gentoo Dependencies.
Einzig Sun ist den Weg aber komplett gegangen und verwendet nur noch ein paar wenige Init-Scripte im "Legacy_Run". Mit einem Ende ist wohl mit Solaris 11 zu erwarten, wenn ich diversen Stimmchen trauen darf.
Statt dessen tritt SVC auf den Plan, welches anhand der einzelnen Abhängigkeitsdefinitionen ganze Bäume erstellt und diese parallel anfahren kann, auch wenn man über Zeitgewinn streiten kann. Andererseits boote ich meine Server nicht so häufig als das ich für einen Streit Energie verschwenden würde. ;-)
 
In SVC sind die alten Runlevel, vor allem rc3 als Solaris Defaultrunlevel als sogenannte "Milestones" aufgeführt. Ein Milestones besteht aus einem Haufen Abhängigkeitsdefinitionen, stellt aber selber keine Dienste zur Verfügung. Beim Booten der Maschine kann man diese Meilensteine - es gibt natürlich auch einen für Singleuser - gezielt anfahren.
Was SVC von den ganzen Alternativen abhebt ist die Tatsache, dass nach meiner Erfahrung nur Solaris 10 in der Lage ist, einen Abbruch wieder korrekt aufzunehmen und damit einen Bootvorgang richtig fortzusetzen. Anders ausgedrückt: Egal was passiert, SVC bietet zu jeder Zeit einen konsistenten Stand des Systems.
 
Kleines Beispiel: Bei der Netzwerk-Konfiguration ist was schief gelaufen und eine Service-IP fehlt z.B. Eine nachgelagerte Apache-Instanz macht darauf aber einen Bind, da die IP aber nicht existiert schlägt der fehl und der Apache wird nicht gestartet.
Mit SVC werden in diesem Falle alle Netzwerkdienste erst garnicht initialisiert. Die grundlegende Netzwerk-Konfiguration wird durch network-physical abgedeckt. Geht die auf failed, werden weder ssh, noch Apache noch sonstwas durch initialisiert.
Spätestens wenn die User anrufen, dass sie sich nicht auf das System konnekten können, kann Admin also hingehen, sieht den Zustand, und kann network-physical fixen.
In dem Moment, wo das passiert ist und der SVC-Service damit in den Status Enabled wechselt, zieht SVC automatisch alle abhängigen Dienste an, ohne das Admin eingreifen muß. Voila...
 
Das ist einer der Gründe, warum ich gerne neue Manifests für Anwendungen schreibe, die wir unter Solaris 10 produktiv nehmen. Dabei offenbaren die Manifests meiner Meinung nach einen Pferdefuß, da es sich hierbei um XML-Dateien handelt.
Ich mag kein XML.
Meiner Meinung nach hat XML bis heute noch nicht bewiesen, daß es das kann, wofür es geschaffen worden ist. Die Import-Funktion, mit der ein neuen Manifest ins SVC-Repository integriert wird, ist da ein gutes Beispiel für. Statt einer ordentlichen Fehlermeldung, weil der Parser irgendwas nicht verstanden hat, kommt nur eine höchst ominöse Meldung a la "es ist ein Fehler aufgetreten".
Aber irgendwas ist ja immer, und ich habe die Hoffnung noch nicht aufgegeben, dass Sun in einer der zukünftigen Versionen dem Parser ein paar ordentliche Meldungen implantieren kann.