In der klassischen System V Welt, d.h. auch unter Linux aber nicht unter Mac OS X, gibt es verschiedene Runlevels zu denen es jeweils ein Unterverzeichnis unterhalb /etc gibt mit Start- und Stopscripten von Diensten.
Startet also der init Prozess (pid 1) auf einem System V UNIX System arbeitet er sukzessive die Startskripte dieser Verzeichnisse ab, wobei zumindest unter Linux einen Nummerierung der Startskripte die Reihenfolge der Abarbeitung festlegt.
Ein nachträglicher Neustart oder das Stoppen ist jederzeit mit solch einem Skript möglich.
Dieses Konzept hat aber mindestens zwei Schwachstellen.
- Das einfügen eines neuen Dienstes ist aufwändig. Neben dem allg. Start-/Stopskript muss in jedem passenden runlevel Unterverzeichnis ein link gesetzt werden, wobei die Nummerierung oftmals nicht eindeutig sein kann.
- Es gibt keinen Supervisor über die Dienste der im Fehlerfall eine Aktion auslösen könnte. Normalerweise wird lediglich im log Bereich protokolliert. Eine respawn Direktive kann diese Situation noch leicht verbessern.
Sun führte deshalb die sog. Service Management Facility (SMF) ein:
Die Skripte der SMF basieren auf XML und lösen die /etc/init.d Skripte ab.
Ein Starten (enable) oder Stoppen (disablen) eines Dienstes ist persistent, es überlebt einen reboot des Systems. Daher ist ein seperater Eintrag in einer inittab/runlevel obsolet.
Alle so gestarteten Dienste werden von einer Art Service Masterdaemon überwacht, dem Holderprozess svc.startd . Die Basis hierfür ist ein Contract System bei der ein zu startender Dienst nebem einer klassischen PID auch eine Contract ID (CTID) bekommt, die direkt dem Holder Prozeß unterstellt ist.
Auch Dämonen die von inetd gestartet werden, besitzen einen SMF Eintrag und werden wie ein stand-alone Dienst gestartet – der Prozess Holder ist dann allerdings inetd, der wiedersum svc.startd untersteht.
Alle Laufzeitinformationen werden in einer sqlite Datenbank gehalten, die einerseits effizient arbeitet andererseits eine mögliche Quelle für einen Totalausfall des Systems darstellt.
Folgender genauerer Überblick über die SMF:
- /lib/svc beinhaltet Administrationsprogramme für die SMF sowie unter „method“ auch die Start-/Stopsckripte zum einmaligen einlesen
- /var/svc beinhaltet die eigentlichen XML Servicebeschreibungen (Manifeste). Das Manifest beinhaltet v.a. Abhängigkeiten gegenüber anderen Diensten und Resourcen, das Fehlerhandling sowie die Start-/Stop Anweisungen die wiederum oft auf ein klassisches Skript in /lib/svc/method verweisen
- /etc/svc beinhalet überraschenderweise das sqlite Repository, welches nicht unter /var/svc angesiedelt ist, sowie logs zum repository.
Beschreibung eines Dienstes, das Manifest:
- beinhaltet den Header
- beschreibt Art und Grad der Abhängigkeit von anderen Diensten/Resourcen
- enthält Start-/Stop Methoden (stop meist mittels :kill definiert)
- definiert spezielle Eigenschaften
- Hinweise zu Dokumentationen
Administration von SMF:
- svcs Service Status, listet alle Dienste des Repositories und Ihren Status auf
- svcs -l detaillierte Ausgabe eines Services incl. CTID der Servicename, bzw. der FRMI (Fault Managed Resource Identifier), kann in der Langform, oder in einer verkürzten Form, falls eindeutig möglich, angegeben werden, bspw: svc:/network/ssh oder auch nur ssh
- svcadm enable/disable ein-/auschalten (online/offline) eines Services
- svcadm restart/refresh durchstarten/erneuern (bei leichten Konf.änderungen)
- svcprop liest die Eigenschaften aus dem Manifest aus
- svccfg Sobald ein XML Manifest einmal in das SMF Repository eingelesen ist (svccfg import) ist diese File unerheblich und nur noch das sqlite Repository maßgebend. svccfg ist ein Tool zur Manipulation dieses Repositories.