Gentoo Logo

Haftungsausschluss: Dieses Handbuch wurde durch eine neuere Version ersetzt und wird nicht länger gepflegt.


[ << ] [ < ] [ Hauptseite ] [ > ] [ >> ]


4. Initskripte

Inhalt:

4.a. Runlevel

Der Startvorgang

Wenn Sie Ihr System booten, werden Sie sehr viel Text auf dem Bildschirm vorbeifließen sehen. Genauer betrachtet, ist es immer derselbe Text nach einem Neustart. Diese Auflistung aller Aktionen beim Startvorgang wird Bootsequenz genannt und ist (mehr oder weniger) fest vorgeschrieben.

Zuerst lädt Ihr Bootloader das Kernel-Image, welches Sie in der Konfigurationsdatei Ihres Bootloaders angegeben haben, in den Arbeitsspeicher. Dann teilt er der CPU mit, den Kernel zu starten. Wenn dieser geladen ist und läuft, initialisiert er alle kernel-spezifischen Strukturen und Aufgaben. Dann wird der init Prozess gestartet.

Dieser Prozess stellt sicher, dass auch alle Dateisysteme (die in /etc/fstab angegeben wurden) gemounted und benutzt werden können. Dann führt er mehrere Skripte in /etc/init.d aus, welche die verschiedenen Dienste starten, die Sie für einen erfolgreichen Bootvorgang benötigen.

Schließlich, wenn alle Skripte ausgeführt wurden, aktiviert init die Terminals (in den meisten Fällen virtuelle Konsolen, die hinter Alt-F1, Alt-F2, etc. versteckt sind) mit einem speziellen Prozess namens getty. Dieser Prozess stellt dann sicher, dass Sie sich über diese Terminals mit dem Befehl login einloggen können.

Initskripte

init führt die Skripte in /etc/init.d aber nicht willkürlich aus. Nur die Skripte aus /etc/init.d, die es ausführen soll, werden auch ausgeführt. Welche das sind, steht in /etc/runlevels.

Zuerst werden alle Skripte aus /etc/init.d, die einen symbolischen Link in /etc/runlevels/boot besitzen, von init gestartet. Normalerweise geschieht dies in alphabetischer Reihenfolge, aber einige Skripte müssen zunächst Abhängigkeiten auflösen, so dass erst andere Skripte gestaret sein müssen, bevor es selbst ausgeführt werden kann.

Wenn alle Skripte aus /etc/runlevels/boot ausgeführt wurden, startet init diejenigen Skripte, die einen symbolischen Link in /etc/runlevels/default besitzen. Auch hier wird zunächst die alphabetische Reihenfolge beachtet, es sei denn, dass auch hier wieder Abhängigkeiten aufgelöst werden müssen, damit eine erfolgreiche Startsequenz gewährleistet ist.

Wie Init arbeitet

Natürlich entscheidet init das alles nicht alleine. Es benötigt eine Konfigurationsdatei, die enthält, welche Aktion ausgeführt werden soll. Diese Datei heißt /etc/inittab.

Wenn Sie sich an die Bootsequenz erinnern, die wir Ihnen eben erklärt hatten, werden Sie sich daran erinnern, dass die erste Aktion von init das Mounten aller Dateisysteme war. Dies ist in der folgenden Zeile aus /etc/inittab ersichtlich:

Befehlsauflistung 1.1: Zeile zur Systeminitialisierung in /etc/inittab

si::sysinit:/sbin/rc sysinit

Diese Zeile teilt init mit, dass es /sbin/rc sysinit ausführen muss, um das System zu initialisieren. Das /sbin/rc Skript stellt dann die Initialisierung sicher. Sie könnten nun sagen, dass init ja eigentlich nicht viel macht -- es delegiert die Aufgabe der Systeminitialisierung an einen anderen Prozess.

Dann führt init alle Skripte, die einen symbolischen Link in /etc/runlevels/boot haben aus. Dies wird in folgender Zeile ersichtlich:

Befehlsauflistung 1.2: Systeminitialisierung, Fortsetzung

rc::bootwait:/sbin/rc boot

Wieder übernimmt das rc Skript die notwendigen Aufgaben. Beachten Sie, dass die Option, die rc (boot) übergeben wird, denselben Namen besitzt, wie das verwendete Unterverzeichnis in /etc/runlevels.

Nun überprüft init seine Konfigurationsdatei, um zu sehen, welchen Runlevel es ausführen sollte. Um dies zu entscheiden, ließt es die folgende Zeile aus /etc/inittab:

Befehlsauflistung 1.3: Die initdefault Zeile

id:3:initdefault:

In diesem Fall (welchen die meisten Gentoo-User nutzen werden) ist die runlevel ID 3. Mit Hilfe dieser Information überprüft init, was alles zum Start von Runlevel 3 ausgeführt werden muss:

Befehlsauflistung 1.4: Runlevel Definitionen

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

Die Zeilen, die den Level 3 definieren, werden wiederum vom rc Skript verwendet, um die Dienste (nun mit dem Argument default) zu starten. Beachten Sie auch hier, dass das Argument von rc wieder denselben Namen wie das verwendete Unterverzeichnis von /etc/runlevels hat.

Wenn rc fertig ist, entscheidet init, welche Konsole es aktivieren sollte und welche Befehle auf jeder Konsole benutzt werden müssen:

Befehlsauflistung 1.5: Die Definition der virtuellen Konsolen

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Was ist ein Runlevel?

Sie haben gesehen, dass init ein Nummernschema benutzt, um zu entscheiden, welchen Runlevel es aktivieren soll. Ein Runlevel ist ein bestimmter Zustand, in dem sich Ihr System befindet und der eine Ansammlung von Skripten (Runlevel-Skripte oder Initskripte) besitzt, die beim Betreten oder Verlassen eines Runlevels ausgeführt werden müssen.

In Gentoo sind sieben Runlevel definiert: drei interne Runlevel und vier, die der Benutzer definieren kann. Die internen Runlevel sind sysinit, shutdown und reboot und machen genau das, was die Namen vermuten lassen: initialisieren das System, fahren es herunter und führen einen Reboot durch.

Die benutzerdefinierten Runlevel sind diejenigen, mit einem Unterverzeichnis in /etc/runlevels: boot, default, nonetwork und single. Der boot Runlevel startet alle notwendigen Dienste, die die anderen Runlevel benötigen. Die verbleibenden drei Runlevel unterscheiden sich in den Diensten, die sie starten: default wird genutzt, um die täglichen Operationen zu erledigen, nonetwork nur im Falle, das keine Netzwerkverbindung gebraucht wird und single, wenn das System repariert werden muss.

Mit den Initskripten arbeiten

Die Skripte, die den rc Prozess starten, werden Initskripte genannt. Jedes Skript in /etc/init.d kann mit den Argumenten start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme oder broken ausgeführt werden.

Um einen Dienst zu starten oder zu stoppen (und die davon abhängigen Dienste), sollte start, stop und restart benutzt werden:

Befehlsauflistung 1.6: Postfix starten

# /etc/init.d/postfix start

Notiz: Nur Dienste, die den gegebenen Dienst benötigen werden gestoppt oder neu gestartet. Alle anderen abhängigen Dienste (die den Dienst nutzen, aber nicht benötigen) werden nicht berührt.

Falls Sie einen Dienst stoppen wollen, aber nicht die davon abhängigen Dienste, können Sie das pause Argument nutzen:

Befehlsauflistung 1.7: Postfix stoppen, ohne die davon abhängigen Dienste zu berühren

# /etc/init.d/postfix pause

Falls Sie den Status eines Dienstes (started, stopped, paused, ...) sehen möchten, können Sie das status Argument nutzen:

Befehlsauflistung 1.8: Statusinformationen über Postfix

# /etc/init.d/postfix status

Falls die Statusinformation Ihnen mitteilt, dass der Dienst gestartet wurde, Sie aber wissen, dass dies nicht der Fall ist, können Sie die Statusinformation mit dem zap Argument zu "stopped" zurücksetzen:

Befehlsauflistung 1.9: Statusinformation von Postfix zurücksetzen

# /etc/init.d/postfix zap

Um auch nachzufragen, was von dem Dienst alles abhängt, können sie die Argumente iuse oder ineed nutzen. Mit ineed wird alles angezeigt, was zum ordnungsgemäßen Funktionieren des Dienstes nötig ist. iuse andererseits zeigt alle Dienste an, die von diesem Dienst benutzt werden können, aber nicht notwendig zur ordnungsgemäßen Funktion des Dienstes sind.

Befehlsauflistung 1.10: Anforderung einer Liste der notwendigen Dienste, von denen Postfix abhängt

# /etc/init.d/postfix ineed

Ähnlich ist die Vorgehensweise, wenn Sie nach allen Diensten fragen wollen, die einen bestimmten Dienst benötigen (needsme) oder ihn benutzen (usesme):

Befehlsauflistung 1.11: Anforderung einer Liste aller Dienste, die Postfix benötigen

# /etc/init.d/postfix needsme

Schließlich können Sie noch nachfragen, welche Abhängigkeiten der Dienst benötigt, die aber noch fehlen:

Befehlsauflistung 1.12: Anforderung einer Liste aller fehlenden Abhängigkeiten für Postfix

# /etc/init.d/postfix broken

4.b. Mit rc-update arbeiten

Was ist rc-update?

Das Init-System von Gentoo benutzt einen Abhängigkeitsbaum um zu entscheiden, welcher Dienst zuerst gestartet werden muss. Da dies eine ermüdende Aufgabe ist, die wir unseren Usern nicht unbedingt zumuten wollten "von Hand" auszuführen, haben wir einige Tools erstellt, die die Administration der Runlevel und Initskripte erleichtert.

Mit rc-update können Sie Initskripte zu einem Runlevel hinzufügen und wieder entfernen. Das rc-update Tool wird dann das depscan.sh Skript automatisch dazu veranlassen, den Abhängigkeitsbaum anzupassen.

Hinzufügen und Entfernen von Diensten

Sie haben bereits während der Installation von Gentoo Initskripte zum "default" Runlevel hinzugefügt. Zu diesem Zeitpunkt hatten Sie aber wahrscheinlich noch keine Ahnung, für was "default" steht, nun sollten Sie es aber wissen. Das rc-update Skript benötigt ein zweites Argument, welches eine "Aktion" definiert: add, del oder show.

Um ein Initskript hinzuzufügen oder zu entfernen, übergeben Sie rc-update einfach add oder del als Argument, gefolgt von dem Initskript und dem Runlevel. Zum Beispiel:

Befehlsauflistung 2.1: Entfernen von Postfix aus dem Runlevel default

# rc-update del postfix default

Der Befehl rc-update -v show wird Ihnen alle verfügbaren Initskripte und Runlevel, in denen diese ausgeführt werden, zeigen:

Befehlsauflistung 2.2: Informationen über Initskripte erhalten

# rc-update -v show

Sie können auch rc-update show ausführen (ohne -v) um nur die aktivierten Initskripte und ihre Runlevel anzuzeigen.

4.c. Dienste konfigurieren

Warum zusätzliche Konfigurationen?

Initskripte können recht komplex sein. Es ist daher nicht unbedingt von Vorteil, wenn User Initskripte direkt bearbeiten könnten, da es die Sache nur fehleranfälliger machen würde. Es ist aber auch wichtig, dass Konfigurationen gemacht werden können. Zum Beispiel, wenn Sie einem Dienst mehrere Optionen mitgeben wollten:

Ein zweiter Grund, diese Konfiguration außerhalb der Initskripte zu haben ist, ein Update eines Initskriptes durchführen zu können, ohne zu befürchten, die Konfigurationen dabei rückgängig zu machen.

Das /etc/conf.d Verzeichnis

Gentoo stellt einen einfachen Weg zur Konfiguration eines solchen Services zur Verfügung: Jedes Initskript, das konfiguriert werden kann, hat eine Datei in /etc/conf.d. Zum Beispiel hat das Apache2 Initskript (/etc/init.d/apache2 genannt) eine Konfigurationsdatei namens /etc/conf.d/apache2, die die Optionen enthalten kann, die Sie dem Apache 2 Server beim Start mitgeben wollen:

Befehlsauflistung 3.1: Variablen, definiert in /etc/conf.d/apache2

APACHE2_OPTS="-D PHP5"

Solch eine Konfigurationsdatei enthält nur Variablen (genau wie in /etc/portage/make.conf), was die Konfiguration eines Dienstes sehr vereinfacht. Es erlaubt uns auch, mehr Informationen (als Kommentare) über die Variablen zu geben.

4.d. Initskripte schreiben

Muss ich das?

Nein. Ein Initskript zu schreiben ist normalerweise nicht notwendig, da Gentoo fertige Initskripte für alle bereitgestellten Dienste liefert. Wie dem auch sei, haben Sie vielleicht einen Dienst, ohne Portage zu nutzen installiert. In diesem Fall müssen sie wahrscheinlich ein eigenes Initskript schreiben.

Benutzen Sie das von einem Dienst bereitgestellte Initskript nicht, es sei denn, es ist ausdrücklich für Gentoo geschrieben: Die Initskripte von Gentoo sind nicht mit den Initskripten anderer Distributionen kompatibel!

Layout

Das grundlegende Layout eines Initskriptes ist wie folgt beschrieben.

Befehlsauflistung 4.1: Grundlegendes Layout eines Initskriptes

#!/sbin/runscript

depend() {
  (Informationen zu Abhängigkeiten)
}

start() {
  (Befehle, notwendig zum Starten eines Dienstes)
}

stop() {
  (Befehle, notwendig zum Stoppen eines Dienstes)
}

Jedes Initskript muss eine start Funktion definieren. Alle anderen Abschnitte sind optional.

Abhängigkeiten

Es gibt zwei Abhängigkeits-artige Einstellungen, die Sie definieren können, die das Starten und die Reihenfolge der Init-Skripte beeinflussen: use und need. Von diesen abgesehen gibt es noch zwei Methoden, die die Reihenfolge beeinflussen: before und after. Diese letzten beiden sind keine eigentlichen Abhängigkeiten - durch sie schlägt das Init-Skript nicht fehl, falls das angegebene Init-Skript nicht zum Starten vorgesehen ist (oder es Probleme mit dem Starten gibt).

  • Die Angabe use informiert das Init-System, dass das Init-Skript Funktionalität des angegebenen Skripts nutzt, aber nicht direkt davon abhängt. Gute Beispiele sind use logger und use dns. Wenn diese Dienste verfügbar sind, können sie für einen guten Zweck verwendet werden, aber auch wenn Sie keinen Logger oder DNS-Server haben, wird der Dienst trotzdem funktionieren. Falls die angegebenen Dienste existieren, werden sie vor dem Skript, das sie benutzt, gestartet.
  • Die Angabe need ist eine harte Abhängigkeit. Sie bedeutet, dass das Skript, das ein anderes Skript benötigt, nicht startet, bevor das andere Skript erfolgreich gestartet hat. Ferner wird dieses Skript neu gestartet, wenn das andere Skript neu gestartet wird.
  • Wenn before genutzt wird, wird das Skript vor dem angegebenen Skript gestartet, falls das angegebene Teil des Init-Levels ist. Beispielsweise wird ein Init-Skript namens xdm, das before alsasound definiert, vor dem Skript alsasound starten, aber nur, wenn alsasound auch im gleichen Init-Level zum Starten vorgemerkt ist. Falls alsasound nicht zum Starten vorgemerkt ist, dann hat diese Einstellung keine Auswirkungen und xdm wird gestartet, wann auch immer das Init-System es für am sinnvollsten hält.
  • Genauso informiert after das Init-System darüber, dass das gegebene Skript nach dem angegebenen Skript gestartet werden soll, falls das angegebene Skript Teil des Init-Levels ist. Falls nicht, hat die Einstellung keine Auswirkungen und das Skript wird gestartet, wann auch immer das Init-System es für am sinnvollsten hält.

Aus diesen Erklärungen sollte hervorgehen, dass need die einzige "wahre" Abhängigkeitseinstellung ist, da sie bestimmt, ob das Skript gestartet wird oder nicht. Alle anderen sind lediglich Hinweise für das Init-System, in welcher Reihenfolge die Skripte gestartet werden können bzw. sollen.

Wenn Sie sich nun einige von Gentoos vielen Init-Skripten anschauen, werden Sie merken, dass einige Abhängigkeiten auf Dinge haben, die keine Init-Skripte sind. Diese "Dinge" nennen wir Virtuals.

Eine virtual Abhängigkeit stellt eine Abhängigkeit dar, die nicht nur von diesem Dienst zur Verfügung gestellt wird. Ihr Initskript kann von einem System-Protokollierdienst abhängen, aber es gibt ja bekanntlich mehrere davon (metalogd, syslog-ng, sysklogd, ...). Da Sie ja nicht jeden einzelnen von diesen brauchen (ein vernünftige System hat nicht jeden dieser Protokollierer installiert und gestartet), stellen wir sicher, dass all diese Dienste eine virtuelle Abhängigkeit bereitstellen.

Lassen Sie uns einen Blick auf die Abhängigkeitsinformationen des Postfix-Dienstes werfen.

Befehlsauflistung 4.2: Abhängigkeitsinformationen zu Postfix

depend() {
  need net
  use logger dns
  provide mta
}

Wie Sie sehen können, der Postfix-Dienst:

  • benötigt die (virtual) net Abhängigkeit (die z.B. von /etc/init.d/net.eth0 bereitgestellt wird)
  • nutzt die (virtual) logger Abhängigkeit (die z.B. von /etc/init.d/syslog-ng bereitgestellt wird)
  • nutzt die (virtual) dns Abhängigkeit (die z.B. von /etc/init.d/named bereitgestellt wird)
  • stellt die (virtual) mta Abhängigkeit (die allen Mail-Servern gemein ist) zur Verfügung

Reihenfolge kontrollieren

Wie im vorherigen Abschnitt beschrieben, können Sie dem Init-System sagen, in welcher Reihenfolge die Skripte gestartet (oder gestoppt) werden sollen. Diese Reihenfolge wird durch die Abhängigkeitsangaben use und need beeinflusst, aber auch durch die Reihenfolgenangaben before und after. Da wir diese Angaben bereits erklärt haben, schauen wir uns beispielhaft das Init-Skript des Dienstes Portmap an.

Befehlsauflistung 4.3: Die depend() Funktion im Portmap-Dienst

depend() {
  need net
  before inetd
  before xinetd
}

Sie können auch den "*" Ausdruck benutzen, um alle Dienste im selben Runlevel zu erwischen, obwohl das nicht sehr ratsam ist.

Befehlsauflistung 4.4: Ein Initskript als erstes in einem Runlevel starten

depend() {
  before *
}

Wenn Ihr Dienst auf lokale Festplatten schreiben muss, wird er wahrscheinlich localmount benötigen. Wenn er etwas in /var/run platziert, wie ein Pidfile, dann sollte er nach bootmisc gestartet werden.

Befehlsauflistung 4.5: Beispiel der depend() Funktion

depend() {
  need localmount
  after bootmisc
}

Standardfunktionen

Neben der depend() Funktionalität benötigen Sie vielleicht auch die start Funktion. Diese enthält alle Befehle, die zum Starten Ihres Dienstes notwendig sind. Es ist ratsam, die ebegin und eend Funktionen zu nutzen, um dem User mitzuteilen, was passiert:

Befehlsauflistung 4.6: Beispiel der start() Funktion

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Befehle, falls ein Restart mehr erfordert als stop, start
  fi

  ebegin "Starten meines Dienstes"
  start-stop-daemon --start --exec /pfad/zu/meinem_dienst \
   --pidfile /pfad/zu/meinem_pidfile
  eend $?
}

Sowohl --exec als auch --pidfile sollten in den Start- und Stopp-Funktionen verwendet werden. Falls der der Dienst kein Pidfile erstellt sollten Sie, wenn möglich, --make-pidfile verwenden. Sie sollten dies aber testen um sicher zu sein. Verwenden Sie ansonsten kein Pidfile. Sie können zudem --quiet zu den start-stop-daemon Optionen hinzufügen; dies wird aber nicht empfohlen, solange der Dienst nicht extrem detailliert berichtet. Die Verwendung von --quiet kann die Fehlersuche behindern, wenn der Dienst nicht erfolgreich gestartet werden kann.

Eine weitere zu bemerkende Einstellung in obigem Beispiel ist das Prüfen des Inhalts der Variable RC_CMD. Im Gegensatz zum alten Init-System unterstützt das neuere System openrc keine Skript-spezifische Restart-Funktionalität. Stattdessen muss das Skript den Inhalt der Variable RC_CMD prüfen, um zu sehen, ob eine Funktion (sei es start() oder stop()) als Teil eines Restarts aufgerufen wird oder nicht.

Notiz: Stellen Sie sicher, dass --exec wirklich einen Dienst aufruft und nicht nur ein Shell-Skript, welches den Dienst startet und dann beendet. Das ist die Aufgabe des Initskripts.

Wenn Sie weitere Beispiele der start() Funktion benötigen, lesen Sie bitte den Quellcode der verfügbaren Initskripte in Ihrem /etc/init.d Verzeichnis.

Eine weitere Funktion, die Sie definieren können, ist stop(). Sie sind nicht verpflichtet, diese Funktion zu erstellen! Unser Init-System ist intelligent genug, diese selbst auszufüllen, sofern Sie den start-stop-daemon nutzen.

Hier ist ein Beispiel einer stop() Funktion:

Befehlsauflistung 4.7: Beispiel der stop() Funktion

stop() {
  ebegin "Stoppen meines Dienstes"
  start-stop-daemon --stop --exec /pfad/zu/meinem_dienst \
    --pidfile /pfad/zu/meinem_pidfile
  eend $?
}

Wenn Ihr Dienst ein anderes Skript ausführt (zum Beipsiel Bash, Python oder Perl) und das Script später den Namen ändert (zum Beispiel von foo.py auf foo) werden Sie --name zum start-stop-daemon hinzufügen müssen. Sie müssen den Namen angeben, auf den Ihr Skript geändert wird. In diesem Beispiel startet ein Dienst foo.py, welches seinen Namen auf foo ändert:

Befehlsauflistung 4.8: Ein Dienst, der das Skript foo startet

start() {
  ebegin "Starten meines Skripts"
  start-stop-daemon --start --exec /pfad/zu/meinem_skript \
    --pidfile /pfad/zu/meinem_pidfile --name foo
  eend $?
}

Für den start-stop-daemon existiert auch eine exzellente man-Seite, falls Sie weitere Informationen benötigen.

Befehlsauflistung 4.9: Aufrufen der man-Seite des start-stop-daemon

$ man start-stop-daemon

Die Syntax für Gentoos Initskripte basiert auf der POSIX-Shell; es steht Ihnen also frei, sh-kompatible Konstrukte innerhalb Ihrer Initskripte zu verwenden. Verwenden Sie keine anderen Konstrukte, z.B. bash-spezifische, um sicherzustellen, dass die Skripte auch dann noch funktionieren, wenn Gentoo Änderungen am Init-System vornimmt.

Eigene Optionen hinzufügen

Falls Sie wollen, dass Ihr Initskript mehr Optionen besitzt, als wir bisher aufgeführt haben, sollten Sie Ihre Option zur extra_commands Variable hinzufügen und eine Funktion mit demselben Namen wie die Option erstellen. Zum Beispiel, um eine Funktion namens restartdelay zu unterstützen:

Befehlsauflistung 4.10: Unterstützung der restartdelay Option

extra_commands="restartdelay"

restartdelay() {
  stop
  sleep 3    # Warte 3 Sekunden vor dem Neustart
  start
}

Wichtig: Die Funktion restart() kann in openrc nicht überschrieben werden!

Variablen zur Dienstkonfiguration

Sie müssen nichts machen, um eine Konfigurationsdatei in /etc/conf.d zu unterstützen: Wenn Ihr Initskript ausgeführt wird, wird folgendes automatisch zu Grunde gelegt (d.h. diese Variablen können benutzt werden):

  • /etc/conf.d/<Ihr Initskript>
  • /etc/conf.d/basic
  • /etc/rc.conf

Falls Ihr Initskript eine virtuelle Abhängigkeit (wie net) bereitstellt, wird dazu die Datei, die mit dieser Abhängigkeit in Verbindung gebracht wird (wie /etc/conf.d/net), auch zu Grunde gelegt.

4.e. Ändern des standardmäßigen Runlevel-Verhaltens

Wer kann hiervon profitieren?

Viele Laptop-Benutzer kennen die Situation: Daheim müssen Sie net.eth0 starten, wenn Sie unterwegs sind möchten sie net.eth0 nicht starten (weil grade kein Netzwerk verfügbar ist). Mit Gentoo können Sie das Runlevel Verhalten nach Ihren eigenen Vorstellungen anpassen.

Zum Beispiel können Sie ein zweites Runlevel "default" anlegen, dass Sie booten können mit anderen Initskripten die diesem Runlevel zugeordnet sind. Sie können während des Booten wählen, welches default Runlevel Sie benutzen möchten.

softlevel benutzen

Zunächst erstellen Sie das Runlevel Verzeichnis für Ihr zweites "default" Runlevel. Als Beispiel werden wir das offline Runlevel erstellen:

Befehlsauflistung 5.1: Erstellen eines Runlevel-Verzeichnisses

# mkdir /etc/runlevels/offline

Fügen Sie die notwendigen Initskripte in das neu erstelle Runlevel. Wenn Sie zum Bespiel eine exakte Kopie Ihres aktuellen default Runlevels anlegen möchten, lediglich ohne net.eth0:

Befehlsauflistung 5.2: Hinzufügen der notwendigen Initskripte

(Kopieren Sie alle Dienste vom default zum offline Runlevel)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Entfernen unerwünschter Dienste vom offline Runlevel)
# rc-update del net.eth0 offline
(Anzeigen aktivierter Dienste für das offline Runlevel)
# rc-update show offline
(Verkürzte Beispielsausgabe)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Obwohl net.eth0 aus dem Runlevel offline entfernt wurde, könnte udev trotzdem versuchen jegliche Geräte, die es findet, zu starten und die passenden Dienste aufzurufen. Diese Funktionalität nennt sich Hotplugging. Standardmäßig verwendet Gentoo kein Hotplugging.

Falls Sie Hotplugging verwenden wollen, aber nur für eine ausgewählte Menge an Skripten, verwenden Sie die rc_hotplug Variable in /etc/rc.conf:

Befehlsauflistung 5.3: Deaktivierung der von Geräten gestarteten Dienste in /etc/rc.conf

# Hotplugging erlauben für net.wlan sowie alle anderen Dienste, die nicht auf net.* matchen

rc_hotplug="net.wlan !net.*"

Notiz: Für weitere Informationen zu Diensten, die von Geräten gestartet werden, schauen Sie sich bitte die Kommentare in /etc/rc.conf an.

Editieren Sie nun die Bootloader-Konfiguration und fügen einen neuen Eintrag für das Runlevel offline hinzu. Zum Beispiel in /boot/grub/grub.conf:

Befehlsauflistung 5.4: Einen zusätzlichen Eintrag für das Runlevel offline hinzufügen

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Voilà, Sie sind soweit. Wenn Sie Ihr System booten und die neu hinzugefügte Option auswählen wird das System das Runlevel offline anstelle des Runlevels default starten.

Bootlevel benutzen

Die Nutzung von bootlevel ist komplett analog zu softlevel. Der einzige Unterschied ist, dass Sie hier ein zweites "boot" Runlevel anstelle eines zweiten "default" Runlevel definieren können.


[ << ] [ < ] [ Hauptseite ] [ > ] [ >> ]


Drucken

Alles ansehen

Seite aktualisiert 31. Oktober 2012

Diese Übersetzung wird nicht länger gepflegt

Zusammenfassung: Gentoo benutzt ein spezielles Initskript Format, welches neben weiteren Features Abhängigkeitsbezogene Entscheidungen und virtuelle Initskripte mitbringt. Dieses Kapitel erklärt diese Aspekte und erklärt, wie Sie mit diesen Skripten umgehen.

Sven Vermeulen
Autor

Grant Goodyear
Autor

Roy Marples
Autor

Daniel Robbins
Autor

Chris Houser
Autor

Jerry Alexandratos
Autor

Seemant Kulleen
Gentoo x86 Entwickler

Tavis Ormandy
Gentoo Alpha Entwickler

Jason Huebel
Gentoo AMD64 Entwickler

Guy Martin
Gentoo HPPA Entwickler

Pieter Van den Abeele
Gentoo PPC Entwickler

Joe Kallar
Gentoo SPARC Entwickler

John P. Davis
Bearbeiter

Pierre-Henri Jondot
Bearbeiter

Eric Stockbridge
Bearbeiter

Rajiv Manglani
Bearbeiter

Jungmin Seo
Bearbeiter

Stoyan Zhekov
Bearbeiter

Jared Hudson
Bearbeiter

Colin Morey
Bearbeiter

Jorge Paulo
Bearbeiter

Carl Anderson
Bearbeiter

Jon Portnoy
Bearbeiter

Zack Gilburd
Bearbeiter

Jack Morgan
Bearbeiter

Benny Chuang
Bearbeiter

Erwin
Bearbeiter

Joshua Kinard
Bearbeiter

Tobias Scherbaum
Bearbeiter

Xavier Neys
Bearbeiter

Gerald J. Normandin Jr.
Korrektor

Donnie Berkholz
Korrektor

Ken Nowack
Korrektor

Lars Weiler
Mitarbeiter

Tobias Scherbaum
Übersetzer

Jens Schittenhelm
Übersetzer

Patrick Sudowe
Übersetzer

Torsten Veller
Übersetzer

Michael Frey
Übersetzer

Markus Nigbur
Übersetzer

Boris Ruppert
Übersetzer

Jan Hendrik Grahl
Übersetzer

Christian Hartmann
Korrektor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.