fork, exec, wait und exit
In de.comp.os.unix.linux.misc fragte jemand:
- Werden in einem Skript die Befehle streng sequentiell ausgeführt, d.h. der nächste erst bearbeitet, wenn der Vorgänger vollständig ausgeführt ist, oder wird automatisch bei unvollständiger Auslastung des Systems bereits der nächste Befehl angefangen?
- Läßt sich das Standardverhalten - wie auch immer es sein mag - bei Bedarf ändern?
Wenn man in ein Shellbuch schaut, wird einem an der einen oder anderen Stelle möglicherweise erläutert, daß die Shell jeden Befehl in einem eigenen Prozeß abarbeitet. Dann wiederum fängt man möglicherweise an zu denken und fragt sich, wie das alles zusammenhängt. Sobald man dort angekommen ist, kann man sich mit dem Unix-Prozeßzyklus beschäftigen.
Prozeß und Programm
Ein Programm ist in Unix eine Serie von ausführbaren Maschineninstruktionen auf der Platte. Man kann mit dem Befehl size einen sehr oberflächlichen Blick auf die Struktur des Programmes werfen oder mit objdump sehr viel mehr Detailinformation bekommen. Der Aspekt, der uns hier interessieren soll: Ein Programm ist eine Folge von Anweisungen und Daten (auf der Platte), die möglicherweise einmal ausgeführt werden.
Ein Prozeß ist ein in Ausführung befindliches Programm. Er besteht aus dem Programm selbst (also der Versammlung von Anweisungen und Daten) und dem aktuellen Zustand der Ausführung. Dazu gehört neben der Memory-Map, die sagt wie das Programm und seine Daten im Speicher angeordnet sind auch der Programmzähler, die Prozessorregister und der Stack des Prozesses, aber auch sein Root-Directory, sein aktuelles Verzeichnis, die Umgebungsvariablen und alle offenen Dateien sowie einigen weiteren Dingen.
Unix behandelt Prozesse und Programme als die verschiedenen Dinge, die es sind: Es ist möglich, ein Programm mehr als einmal auszuführen - es ist zum Beispiel möglich, mehr als eine Kopie des Texteditors vi offen zu haben, die zwei unterschiedliche Texte bearbeiten. Programm und (initiale) Daten beider Prozesse sind gleich, aber der Zustand beider Prozesse ist verschieden. Es ist auch möglich, im selben Prozeß nacheinander mehr als ein Programm auszuführen - dazu schmeißt sich das aktuelle Programm in dem Prozeß selbst weg und ersetzt sich durch ein zweites, in diesen Prozeß nachgeladene Programm.
Unix regelt all diese Dinge mit vier sehr einfachen Systemkonzepten -
fork(), exec(), wait() und exit().
Usermode und Kernel
Prozeßwechsel: Es wird ein Stück Prozeß 1 abgearbeitet, dann (1) auf Prozeß 2 umgeschaltet. Nach einer Weile wird (2) wieder auf Prozeß 1 zurück geschaltet. Die Ausführung von Prozeß 1 erscheint lückenlos, erfolgt aber in zeitlich nicht zusammenhängenden Intervallen.
Wenn ein Unix-Prozeß eine Systemfunktion aufruft (und noch bei ein paar anderen Gelegenheiten), dann verläßt der betreffende Prozeß seinen Userkontext und betritt den privilegierten Betriebsystemkern, den Kernel. Dort wird die aufgerufene Systemfunktion ausgeführt und danach landet jede dieser Funktionen im Scheduler. Der Scheduler entscheidet dann, welcher Prozeß als nächstes dran kommt und kehrt aus dem Kernel in diesen Prozeß zurück. Das kann unser Ausgangsprozeß oder nach Entscheidung des Schedulers ein anderer Prozeß sein.
Wir halten für die Zwecke diese Textes fest: Jeder Systemaufruf wechselt vom Userkontext in den Kernel. Der einzige Weg aus dem Kernel in einen Userkontext führt durch den Scheduler, und dann kehren wir unter Umständen nicht in den Ausgangsprozeß zurück. Bei jedem Systemaufruf kann ein Prozeß also seine CPU verlieren.
Das ist nicht schlimm, weil dieser andere Prozeß auch irgendwann einmal die CPU aufgeben muß und wir dann in unseren eigenen Prozeß zurück kehren als sei nichts gewesen.
Unser Programm wird also nicht linear abgearbeitet, sondern in kurzen linearen Segmenten, zwischen denen Pausen liegen können. In den Pausen arbeitet die CPU an den Segmenten der anderen Prozesse, die ebenfalls lauffähig sind.
fork() und exit()
In traditionellem Unix ist der Systemaufruf fork() die einzige Methode,
einen neuen Prozeß zu erzeugen. Der neue Prozeß enthält eine Kopie des
laufenden Programmes. Er hat eine neue Prozeß-ID und die Prozeß-ID des
Erzeugers ist als seine Parent Prozeß-ID (PPID) eingetragen.
Im Parent-Prozeß kehrt fork() mit der PID des neuen Prozesses als Ergebnis
zurück. Der neue Prozeß kehrt ebenfalls aus dem Systemaufruf fork() zurück,
liefert dort aber das Resultat 0.
Der Systemaufruf fork() ist also insofern besonders, als daß er einmal
betreten wird, aber zweimal verlassen wird: Einmal im Elternprozeß und
einmal im neu erzeugten Kindprozeß. fork() erhöht die Anzahl der laufenden
Prozesse im System um eins.
Jeder Unix-Prozeß beginnt seine Existenz also, indem er aus einem
fork()-Systemaufruf spontan zurückkehrt und ein Programm ausführt, daß
eine Kopie des Elternprogrammes ist. Sein Schicksal unterscheidet sich vom
Schicksal des Elternprozesses, weil das Ergebnis des fork()-Aufrufes
unterschiedlich ist (0 statt der PID des Kindes) und man dies zur
Verzweigung nutzen kann.
In Code:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
main(void) {
pid_t pid = 0;
pid = fork();
if (pid == 0) {
printf("Ich bin der Kindprozess.\n");
}
if (pid > 0) {
printf("Ich bin der Elternprozess, das Kind ist %d.\n", pid);
}
if (pid < 0) {
perror("In fork():");
}
exit(0);
}
und
kris@linux:/tmp/kris> make probe1
cc probe1.c -o probe1
kris@linux:/tmp/kris> ./probe1
Ich bin der Kindprozess.
Ich bin der Elternprozess, das Kind ist 16959.
Wir vereinbaren also eine Variable pid vom Typ pid_t.
Diese Variable speichert das Ergebnis des Systemaufrufes fork() und mit
Hilfe dieses Wertes aktivieren wir entweder das eine (“Ich bin der
Kindprozeß”) oder das andere (“Ich bin der Elternprozeß”) if().
Starten wir das Programm, erhalten wir zwei Ausgaben. Da innerhalb eines Prozesses nur ein Status existieren kann und nur eines der beiden if() betreten werden kann, wir aber zwei Ausgaben erhalten haben, müssen wir zwei Prozesse erzeugt haben.
Indem wir das Ergebnis von getpid() druckten, könnten wir das sogar noch
anschaulicher zeigen.
Der Systemaufruf fork() wird einmal betreten, aber zweimal verlassen und
erhöht die Anzahl der Prozesse im System um eins. Nach dem Ablauf unseres
Programmes ist die Anzahl der Prozesse im System aber wieder genauso hoch
wie vor dem Aufruf des Programmes. Es muß also einen weiteren Systemaufruf
geben, der die Anzahl der Prozesse im System um eins erniedrigt.
Dieser Aufruf ist exit().
exit() wird einmal betreten und nie verlassen. Er verkleinert die Anzahl
der Prozesse im System um eins. exit() liefert außerdem einen Exitstatus,
den der Elternprozeß abholen kann (oder gar muß) und der ihn über das
Schicksal seines Kindes informiert.
In unserem Beispiel enden alle Varianten unseres Programmes mit exit() -
wir rufen exit() also im Elternprozeß und im Kindprozeß auf, beenden also
zwei Prozesse. Das können wir nur deswegen tun, weil unser Elternprozeß auch
ein Kindprozeß ist und zwar ein Kind der Shell.
Die Shell arbeitet also genau wie wir:
bash (16957) --- erzeugt durch fork() ---> bash (16958) --- wird zu ---> probe1 (16958)
probe1 (16958) --- erzeugt durch fork() ---> probe1 (16959) --> exit()
|
+---> exit()
exit() schließt alle Dateien und Internetverbindungen eines Prozesses,
gibt allen Speicher frei und beendet dann den Prozeß. Der Parameter von
exit(), der Exitstatus, wird an den Elternprozeß zurückgegeben.
wait()
Der Kindprozeß endet durch ein exit(0). Die 0 ist der Exitstatus unseres
Programmes und steht nun zur Abholung bereit. Wir müssen im Elternprozeß den
Exitstatus abholen. Dies geschieht mit der Systemfunktion wait().
In Code:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
main(void) {
pid_t pid = 0;
int status;
pid = fork();
if (pid == 0) {
printf("Ich bin der Kindprozess.\n");
sleep(10);
printf("Ich bin der Kindprozess 10 Sekunden spaeter.\n");
}
if (pid > 0) {
printf("Ich bin der Elternprozess, das Kind ist %d.\n", pid);
pid = wait(&status);
printf("Ende des Prozesses %d: ", pid);
if (WIFEXITED(status)) {
printf("Der Prozess wurde mit exit(%d) beendet.\n", WEXITSTATUS(status));
}
if (WIFSIGNALED(status)) {
printf("Der Prozess wurde mit kill -%d beendet.\n", WTERMSIG(status));
}
}
if (pid < 0) {
perror("In fork():");
}
exit(0);
}
und
kris@linux:/tmp/kris> make probe2
cc probe2.c -o probe2
kris@linux:/tmp/kris> ./probe2
Ich bin der Kindprozess.
Ich bin der Elternprozess, das Kind ist 17399.
Ich bin der Kindprozess 10 Sekunden spaeter.
Ende des Prozesses 17399: Der Prozess wurde mit exit(0) beendet.
Die Variable status wird dem Systemaufruf wait() als Referenzparameter
mit übergeben und von diesem überschrieben. Neben dem Exitstatus finden wir
dort auch noch weitere Informationen über den Grund des Programmendes
hinterlegt. Zur Decodierung stellt das System eine Reihe von Prädikaten wie
WIFEXITED() oder WIFSIGNALED() zur Abfrage bereit und Extraktoren wie
WEXITSTATUS() und WTERMSIG(). wait() gibt außerdem die Prozeß-ID des
Prozesses zurück, der beendet wurde.
wait() hängt im Elternprozeß so lange bis entweder ein Signal eintrifft
oder ein Kindprozeß beendet wird.
Das Programm init mit der PID 1 macht übrigens den ganzen lieben langen Tag
nix anderes: Es hängt im wait() und frühstückt die ihm zugeworfenen
Exitstati ab, um sie zu verwerfen. Außerdem liest es die /etc/inittab und
startet die dort konfigurierten Programme. Ist eines dieser Programme auf
Respawn gesetzt und wird beendet, wird es von init neu gestartet.
Beendet sich ein Kindprozeß, ohne daß der Elternprozeß ein wait() macht,
zerstört exit() schon einmal alle Datenstrukturen des Kindprozesses, kann
jedoch den Prozeßlisteneintrag des Prozesses noch nicht wegwerfen, denn hier
steht der Exitstatus des Kindes drin. Es könnte ja nun sein, daß der
Elternprozeß sich irgendwann entschließt, ein wait() auszuführen und dann
muß der Exitstatus ja bereitstehen.
Der Kindprozeß ist also bereits tot - er hat exit() ausgeführt und alle
Ressourcen freigegeben, kann aber noch nicht sterben, weil ja der
Elternprozeß den Status noch nicht abgeholt hat. Unix nennt so einen Prozeß
einen Zombie-Prozeß. Zombies werden in der Prozeßliste sichtbar, wenn ein
Prozeßerzeuger falsch programmiert ist und nicht ausreichend wait() aufruft.
Anders herum ist es auch möglich, daß ein Kindprozeß weiter läuft, während ein Elternprozeß beendet wird. Dann wird die Parent Prozeß-ID (PPID) des Kindes von der PID des Elternprozesses auf die Konstante 1 geändert, oder in anderen Worten - init erbt den Prozeß.
Beendet sich das Kind, empfängt init den Exitstatus des Kindes, denn init hängt ja sowieso dauernd im wait. Dadurch wird die Entstehung eines Zombies in diesem Fall verhindert.
Wenn die Anzahl der Prozesse im System über die Laufzeit des System im
Mittel konstant ist, dann ist die Anzahl der fork(), exit() und
wait()-Aufrufe im System ebenfalls im Mittel gleich, denn für jedes
fork() muß irgendwann einmal ein exit() gemacht werden und für jedes
exit() muß der Elternprozeß einmal ein wait() machen (In Wirklichkeit
ist die Situation wegen einiger anderer Regeln noch ein wenig komplizierter,
aber erst einmal soll dies hier genügen).
Wir haben also ein sauberes fork-exit-wait-Dreieck.
exec()
So wie fork() Prozesse erzeugt, so lädt exec() Programme in einen Prozeß.
In Code:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
main(void) {
pid_t pid = 0;
int status;
pid = fork();
if (pid == 0) {
printf("Ich bin der Kindprozess.\n");
execl("/bin/ls", "ls", "-l", "/tmp/kris", (char *) 0);
perror("In exec(): ");
}
if (pid > 0) {
printf("Ich bin der Elternprozess, das Kind ist %d.\n", pid);
pid = wait(&status);
printf("Ende des Prozesses %d: ", pid);
if (WIFEXITED(status)) {
printf("Der Prozess wurde mit exit(%d) beendet.\n", WEXITSTATUS(status));
}
if (WIFSIGNALED(status)) {
printf("Der Prozess wurde mit kill -%d beendet.\n", WTERMSIG(status));
}
}
if (pid < 0) {
perror("In fork():");
}
exit(0);
}
kris@linux:/tmp/kris> make probe3
cc probe3.c -o probe3
kris@linux:/tmp/kris> ./probe3
Ich bin der Kindprozess.
Ich bin der Elternprozess, das Kind ist 17690.
total 36
-rwxr-xr-x 1 kris users 6984 2007-01-05 13:29 probe1
-rw-r--r-- 1 kris users 303 2007-01-05 13:36 probe1.c
-rwxr-xr-x 1 kris users 7489 2007-01-05 13:37 probe2
-rw-r--r-- 1 kris users 719 2007-01-05 13:40 probe2.c
-rwxr-xr-x 1 kris users 7513 2007-01-05 13:42 probe3
-rw-r--r-- 1 kris users 728 2007-01-05 13:42 probe3.c
Ende des Prozesses 17690: Der Prozess wurde mit exit(0) beendet.
Hier wird im Sohnprozeß der Code von probe3 weggeworfen (Das perror("In exec():") wird niemals ausgeführt) und durch den angegebenen Aufruf von
ls ersetzt. In der Ausführung erkennen wir, daß probe3 wartet, bis das
ls sich mit exit() beendet hat und dann seine eigene Ausführung danach
fortsetzt.
Als Shellscript
Die Beispiele oben operieren in C. In bash sieht es so aus:
kris@linux:/tmp/kris> cat probe1.sh
#! /bin/bash --
echo "Starte Kindprozess"
sleep 10 &
echo "Der Kindprozess hat die ID $!"
echo "Der Elternprozess hat die ID $$"
echo "$(date): Elternprozess geht schlafen."
wait
echo "Der Kindprozess $! hat den Exit-Status $?"
echo "$(date): Elternprozess ist aufgewacht."
kris@linux:/tmp/kris> ./probe1.sh
Starte Kindprozess
Der Kindprozess hat die ID 18071
Der Elternprozess hat die ID 18070
Fri Jan 5 13:49:56 CET 2007: Elternprozess geht schlafen.
Der Kindprozess 18071 hat den Exit-Status 0
Fri Jan 5 13:50:06 CET 2007: Elternprozess ist aufgewacht.
Und hier beobachten wie die Shell bei der Ausführung von Kommandos:
kris@linux:~> strace -f -e execve,clone,fork,waitpid bash
kris@linux:~> ls
clone(Process 30048 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7dab6f8) = 30048
[pid 30025] waitpid(-1, Process 30025 suspended
<unfinished ...>
[pid 30048] execve("/bin/ls", ["/bin/ls", "-N", "--color=tty", "-T", "0"],
[/* 107 vars */]) = 0
...
Process 30025 resumed
Process 30048 detached
<... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED
WCONTINUED) = 30048
--- SIGCHLD (Child exited) @ 0 (0) ---
...
Linux verwendet eine Verallgemeinerung von fork() mit dem Namen clone() um
einen Kindprozeß zu erzeugen. Daher sehen wir keinen fork(), sondern einen
clone()-Aufruf mit einigen Parametern.
Linux verwendet außerdem die Variante waitpid() von wait(), um auf eine
bestimmte PID zu warten.
Linux startet außerdem das Programm mit execve() statt mit execl(), aber
das ist nur eine andere Anordnung von Parametern. Nach dem Ende von ls
(PID 30048) wird der Prozeß 30025 aus dem wait() erweckt und fortgesetzt.
Und
hier
ist
der C-Code der Originalshell aus dem Jahre 1979, mit dem fork() (Man suche
nach “case TFORK:” und wundere sich nicht über den Programmierstil von Herrn
Bourne). Ja, bash ist schöner - GNU Code oder nicht.
(nach einem News-Artikel von mir)