Den meisten Linux-Admins ist es nach längerer Zeit in der Praxis schon in Fleisch und Blut übergegangen: Sie tippen »/etc/init.d/
«
und drücken dann die [Tab]-Taste, wenn sie einen Serverdienst starten oder stoppen wollen. Bei (Open) Solaris übernimmt dies das Service Management Facility (SMF), das unter anderem Hintergrundprozesse (Daemons) verwaltet. Es löst damit die klassischen RC-Skripte ab, die Linux-Benutzer gewohnt sind. Ihre Funktionalität reicht aber noch weiter. Das SMF dient zusätzlich auch der Handhabung von Geräten und den Milestones, also von den Runlevels abgeleiteten Services.
Das SMF ermöglicht die einheitliche Verwaltung der Services für den Start, das Beenden und die Fehlerbehandlung. Dabei identifiziert der Fault Management Resource Identifier (FMRI) einen Dienst im System. Der FMRI enthält den Service- und Instanznamen, er ist in der Form
svc:/Service:Instanz
aufgebaut. In folgendem Beispiel
svc:/network/login:rlogin
bezeichnet »/network/login
«
den Service und »rlogin
«
die Service-Instanz. Die Angaben werden immer mit »svc:
«
eingeleitet. Der Daemon »svc.startd
«
ist der Masterprozess-Starter und -Restarter für das Betriebssystem. Die Services werden in die Kategorien
eingeteilt. Diese Einteilung zu beachten ist für jene Administratoren wichtig, die Anwendungen außerhalb des Paketsystems installieren und mittels SMF verwalten wollen. Jeder eingetragene Service besitzt automatisch auch einen Status (Tabelle 1).
Tabelle 1
Service-Status
Status | Bedeutung |
---|---|
online |
Service wurde aktiviert und erfolgreich gestartet |
offline |
Service wurde aktiviert, aber nicht gestartet |
degraded |
Service wurde aktiviert, aber mit eingeschränkten Ressourcen gestartet |
maintenance |
Service wurde aktiviert, beim Start trat ein noch zu klärender Fehler auf |
uninitialized |
Ausgangsstatus aller Services vor dem Einlesen der Konfiguration |
legacy run |
Start über klassisches RC-Skript, nur Überwachung durch SMF möglich |
disabled |
Service ist nicht aktiviert und nicht gestartet |
Die RC-Skripte legt der Open-Solaris-Administrator unter »/etc/init.d
«
mit Symlinks im passenden Runlevelverzeichnis ab (»/etc/rc.Runlevel.d
«
). Sowohl der Start beim Hochfahren des Systems als auch die manuelle Vorgehensweise funktionieren wie üblich. Auf diese Weise gestartete Prozesse stellen die SMF-Werkzeuge in der Form »lrc:/etc/RC-Verzeichnis/RC-Skript
«
dar.
Open Solaris kennt nach wie vor die klassischen Runlevels. Mit Hilfe von »init Runlevel
«
beziehungsweise mit dem entsprechenden Befehl (etwa »reboot
«
) wechselt es wie jedes andere Unix-artigen Betriebssystem den Runlevel, startet das System neu oder fährt es herunter. Milestones kennzeichnen ähnlich wie Runlevels einen definierten Stand an aktiven oder nicht aktiven Services. Einige entsprechen Runlevels. Das Handbuch rät allerdings (noch) davon ab, mittels SMF die bisherige Handhabung der Runlevels zu ersetzen, obwohl dies teilweise möglich wäre.
Der Standard-Runlevel ist 3, der Standard-FRMI heißt »milestone:/multi-user -server:default
«
. Mittels »/usr/bin/who -r
«
kann am laufenden System der aktuelle Runlevel ermittelt werden:
/usr/bin/who -r . run-level 3 Jan 22 19:07 3 0 S
In diesem Beispiel ist der aktuelle Runlevel »3
«
. Dies zeigt das Kommando doppelt an, zusammen mit dem Zeitpunkt, seit wann der aktuelle Runlevel aktiv ist. Die folgende Angaben verraten, wie oft seit dem letzten Reboot dieser Runlevel erreicht wurde (0-mal) und welcher der vorhergehende war (S).
Tabelle 2
Runlevel und Milestone
Runlevel | FMRI | Zweck |
---|---|---|
0 |
– |
Herunterfahren des Systems, ohne abzuschalten |
s/S |
milestone:/single-user:default |
Ein-Benutzer-Modus mit teilweise eingehängten Dateisystemen |
1 |
– |
Wie » |
2 |
milestone:/multi-user:default |
Mehr-Benutzer-Modus, alle Services außer NFS gestartet |
3 |
milestone:/multi-user-server:default |
Wie » |
4 |
– |
Weiterer Mehr-Benutzer-Modus, für eigene Erweiterungen |
5 |
– |
Herunterfahren und Abschalten des Systems |
6 |
– |
Neustart des Systems |