init

Um die Gestaltung des Benutzersystems maximal flexibel zu halten, versucht der Kernel, das eigentliche init-Kommando als externes Programm vom Root-Filesystem zu laden. Um überhaupt auf das Root-Filesystem zugreifen zu können, wird als erster Schritt der setup(2)-Systemcall durchgeführt, der wieder in den Kernelmodus zurückschaltet und dort die Festplatten initialisiert. Wenn der Kernel eine RAM-Disk angelegt hat, versucht er, sie von der Bootdiskette zu laden. Bevor der Systemcall beendet und wieder zum init-Prozeß in den Benutzermodus gewechselt wird, wird das Root-Filesystem gemountet.

Die wichtigste Aufgabe des init-Prozesses ist die Eröffnung der interaktiven Oberfläche, ohne die keine Benutzeraktivität am Rechner möglich wäre. Zu diesem Zweck werden von init auf allen Ports, auf denen das Einloggen möglich sein soll, getty-Prozesse erzeugt. Um nach der Beendigung einer Session auf einem bestimmten Port immer wieder ein Login zu ermöglichen, wird von dem besonderen Eltern-Kind-Verhältnis zwischen erzeugendem und erzeugtem Prozeß Gebrauch gemacht: das init-Programm bekommt automatisch ein Signal vom Kernel, wenn der Kindprozeß zu Ende ist, und kann ihn sofort neu starten.

Der Name ` init' deutet auf eine weitere Aufgabe des Programms hin: Es initialisiert das System. Dazu werden bestimmte Shellprogramme interpretiert. Weil diese Scriptdateien auf einfache Weise von der Systemverwalterin erstellt und verändert werden können, kann diese Phase der Systeminitialisierung im Gegensatz zur Kernelinitialisierung vollständig von der Systemverwalterin konfiguriert werden.

Für Linux sind zwei sehr verschiedene Versionen von init verbreitet:

Das einfache init (simpleinit) von Peter Orbaek mit Erweiterung von Werner Almesberger beschränkt sich auf die wesentlichen Aufgaben: es wird ein einziges Shellscript, die Datei /etc/rc, der Standardshell zur Interpretation übergeben, und es werden die in der Datei /etc/inittab bestimmten virtuellen Terminals und seriellen Schnittstellen mit einem getty-Prozeß belegt. Für spezielle Situationen kann das simpleinit in einem speziellen Einbenutzermodus (single user mode) gestartet werden. In diesem Modus wird das Initialisierungsscript nicht interpretiert, und es wird nur eine einzige Shell mit Root-Rechten gestartet.

Das vielseitigere, und damit natürlich auch kompliziertere, System V kompatible init Programm von Mike Jagdis und Miquel van Smoorenburg erlaubt eine Vielzahl von Systemzuständen, sogenannte Runlevel, bei denen die unterschiedlichsten Prozesse oder Dienste gestartet und Initialisierungen durchgeführt werden.

Simpleinit

Wie bereits oben gesagt, bietet das simpleinit zwei Modi an. Im Einbenutzermodus wird nur eine einzige Shell auf der Konsole gestartet. Auf den anderen virtuellen Terminals kann nicht gearbeitet werden. Das System startet im Einbenutzermodus, wenn die Datei /etc/singleboot existiert oder wenn auf der Kommandozeile des Kernels das Schlüsselwort single angegeben wurde. Wenn außerdem die Datei /etc/securesingle existiert, muß das korrekte Rootpaßwort eingegeben werden, bevor init die Shell öffnet.

Wenn die Einbenutzershell verlassen wird, fährt das System automatisch in den Mehrbenutzermodus hoch. Erst beim Übergang in den Mehrbenutzermodus wird die Systeminitialisierungsdatei /etc/rc abgearbeitet. Außer den getty-Prozessen für die Terminals werden vom simpleinit nach der Ausführung des Shellscripts keine weiteren Programme gestartet. Das bedeutet, daß alle darüber hinaus notwendigen Systeminitialisierungen in diesem Shellscript durchgeführt werden müssen.

# /etc/rc

# Das Root-Filesystem ist Read-Only gemountet.
# Zuerst werden die Dateisysteme getestet...
echo "Dateisysteme werden geprueft..."
/sbin/fsck -A -a
if [ $? -gt 1 ] ; then
        echo "Fehler im Dateisystem gefunden. Bitte neu booten!"
        /bin/sh
fi

# ...dann wird das Root-Filesystem mit Schreiberlaubnis remountet.
/sbin/mount -n -o remount /dev/hda1 /

# Hier werden zur Sicherheit ein paar Dateien entfernt.
/bin/rm -f /etc/mtab* /etc/nologin
/bin/cat /dev/null > /etc/utmp

# Hier wird der Rest des Dateisystems ohne das NFS gemountet
# und die Swappartition aktiviert.
/sbin/mount -avt nonfs
/sbin/swapon -a

# Mit den Scriptdateien rc.inet? wird das TCP/IP Networking
# gestartet.
/bin/sh /etc/rc.inet1
/bin/sh /etc/rc.inet2

# Die Systemuhr wird aus dem CMOS gelesen.
/usr/sbin/clock -u -s

# Einige Daemonen werden gestartet.
echo -n "Starting daemons: "
/usr/sbin/crond
/usr/sbin/lpd
# Der update oder bdflush Prozess muss unbedingt im
# rc-Script gestartet werden.
/sbin/update &

# Die Tastaturtabelle wird geladen.
/sbin/loadkeys /etc/keytables/gr-latin1.map

# Schliesslich wird noch das lokale Initialisierungscript
# aufgerufen.
/bin/sh /etc/rc.local

Nachdem das Shellscript /etc/rc abgearbeitet ist, liest das simpleinit die Datei /etc/inittab, in der ausschließlich die getty-Prozesse gestartet werden, mit denen das Einloggen auf den verschiedenen Terminals erst möglich wird.

# inittab fuer simpleinit
# Format: tty-Port:termcap-Eintrag:getty-Kommando
#
# Die ersten fuenf Zeilen sind fuer die virtuellen Terminals...
#
tty1:con100x40:/sbin/getty 9600 tty1
tty2:con100x40:/sbin/getty 9600 tty2
tty3:con100x40:/sbin/getty 9600 tty3
tty4:con100x40:/sbin/getty 9600 tty4
#tty5:con100x40:/sbin/getty 9600 tty5
#
# ...die letzte Zeile ist fuer den Modem-Port.
#
ttyS1:vt102:/sbin/getty 9600 ttyS1

Die Syntax für das getty-Kommando hängt von der Version ab. Jeder dieser getty Prozesse wird in einer Art Endlosschleife immer wieder erzeugt, wenn die Loginshell auf dem zugehörigen Terminal verlassen wird. Das bedeutet auch, daß der init Prozeß niemals wirklich beendet wird.

Es besteht aber die Möglichkeit, mit einem ` kill -1 1' das init-Programm zu veranlassen, die /etc/inittab neu zu lesen und entsprechend den dann gefundenen Zeilen die getty-Prozesse neu zu starten. Noch vorhandene alte getty werden vom simpleinit nicht automatisch beendet. Diese Prozesse müssen einzeln direkt von der Systemverwalterin beendet werden.

Sysvinit

Wie bereits weiter oben gesagt, bietet das System-V-kompatible init durch die Runlevel  eine sehr flexible Methode zur Systemkonfiguration. In jedem Runlevel werden bestimmte Dienstprogramme und Dämonen gestartet, andere werden beim Übergang in einen neuen Modus beendet, und es können für jeden Runlevel eigene Konfigurationsscripts aufgerufen werden.

In welchem Runlevel welche Programme laufen, und welche Initialisierungsdateien abgearbeitet werden sollen, das wird in der Datei /etc/inittab (eventuell auch sysvinittab) festgelegt. Diese Datei enthält Datensätze, deren Bedeutung bei der Reise durch das Dateisystem auf der Seite beschrieben wird.

Zur Änderung des Runlevels gibt es das telinit-Kommando, das als einzigen Kommandozeilenparameter den Namen oder das Zeichen (Buchstabe oder Ziffer) des gewünschten Runlevels erwartet. Dieses Kommando kann nur von der Superuserin ausgeführt werden.