1.9 Vom Shellscript zum Prozess 

Ein Prozess ist nichts anderes als ein Programm bei der Ausführung. Geben Sie bspw. in einer Shell das Kommando pwd ein, wird Ihnen das aktuelle Verzeichnis angezeigt, in dem Sie sich gerade befinden. Zwar ist hier häufig die Rede von einem Kommando, doch letztendlich ist dies auch nur ein Prozess bei der Ausführung.

Diesem Prozess (wir bleiben einfach mal beim Kommando pwd) steht zur Ausführungszeit die komplette Verwaltungseinheit des Betriebssystems zur Verfügung, so als wäre dies das einzige Programm, das gerade läuft. Vereinfacht heißt dies, dass im Augenblick der Ausführung dem Kommando pwd die komplette Rechenleistung der CPU (Prozessor) zur Verfügung steht. Natürlich ist diese alleinige Verfügbarkeit zeitlich begrenzt, denn sonst würde es sich ja nicht um ein Multitasking-Betriebssystem handeln. Gewöhnlich werden auf einem Betriebssystem mehrere Programme gleichzeitig ausgeführt. Auch dann, wenn Sie noch gar kein Programm gestartet haben, laufen viele Dienste – und je nach Einstellung auch Programme – im Hintergrund ab (Daemon-Prozesse).

In der Praxis hat es den Anschein, als würden alle Prozesse zur gleichen Zeit ausgeführt. Dies ist aber nicht möglich, da ein Prozess im Augenblick der Ausführung eine CPU benötigt, und allen anderen Prozessen eben in dieser Zeit keine CPU zur Verfügung steht. Anders hingegen sieht dies natürlich aus, wenn mehrere CPUs im Rechner vorhanden sind. Dann wäre theoretisch die Ausführung von mehreren Prozessen (echtes Multithreading) gleichzeitig möglich – pro CPU eben ein Prozess.

Jeder dieser Prozesse besitzt eine eindeutige systemweite fortlaufende Prozessnummer (kurz PID für Process Identification Number). Vom Betriebssystem selbst wird sichergestellt, dass hierbei keine Nummer zweimal vorkommt. Stehen bei der Vergabe von PIDs keine Nummern mehr zur Verfügung, wird wieder bei 0 angefangen (bereits vergebene Nummern werden übersprungen). Natürlich können nicht unendlich viele Prozesse ausgeführt werden, sondern dies ist abhängig von der Einstellung des Kernels (wo mindestens 32768 Prozesse garantiert werden). Dieser Wert kann zwar nach oben »gedreht« werden, das fordert dann allerdings auch mehr Hauptspeicher, da die Prozessliste nicht ausgelagert (geswapt) werden kann.

Zur Überwachung von Prozessen sind des Administrators liebste Werkzeuge die Kommandos ps und top geworden (natürlich gibt es auch grafische Alternativen zu diesen beiden System-Tools). Das Kommando ps liefert Ihnen Informationen über den Status von aktiven Prozessen. Mit ps lässt sich die aktuelle PID, die UID, der Steuerterminal, der Speicherbedarf eines Prozesses, die CPU-Zeit, der aktuelle Status des Prozesses und noch eine Menge mehr anzeigen. Da ps allerdings nur den momentanen Zustand von Prozessen ausgibt, kann man nie genau sagen, wo gerade wieder mal ein Prozess Amok läuft. Für eine dauerhafte Überwachung von Prozessen wurde das Kommando top entwickelt. Abhängig von der Einstellung aktualisiert top die Anzeige nach einigen Sekunden (laut Standardeinstellung meistens nach 3 Sekunden) und verwendet dazu auch noch relativ wenig Ressourcen in Ihrem System.

Ein grundlegendes Prinzip unter Linux/UNIX ist es, dass ein Prozess einen weiteren Prozess starten kann. Dieses Prinzip wurde bereits beschrieben, als es darum ging, ein Shellscript auszuführen. Dabei startet die Login-Shell eine weitere Shell (also einen weiteren Prozess). Erst die neue Shell arbeitet jetzt Zeile für Zeile das Shellscript ab. Hier haben Sie ein Eltern-Kind-Prinzip. Jeder Kindprozess (abgesehen von »init« mit der PID 1) hat einen Elternprozess, der ihn gestartet hat. Den Elternprozess kann man anhand der PPID-Nummer (PPID = Parent Process Identifier) ermitteln. So können Sie die ganze Ahnengalerie mithilfe von ps –f nach oben laufen:

you@host > ps -f
UID        PID  PPID  C STIME TTY          TIME CMD
tot       3675  3661  0 10:52 pts/38   00:00:00 /bin/bash
tot       5576  3675  0 12:32 pts/38   00:00:00 ps -f

Hier wird bspw. der eben ausgeführte Prozess ps –f mit der PID 5576 aufgelistet. Der Elternprozess, der diesen Prozess gestartet hat, lautet 3675 (siehe PPID) – was die PID der aktuellen bash (hier eine Zeile höher) ist. Die komplette Ahnengalerie können Sie aber auch etwas komfortabler mit dem Kommando pgrep (siehe Kapitel 14, Linux-UNIX-Kommandoreferenz) ermitteln.

1.9.1 Ist das Shellscript ein Prozess? 

Diese Frage kann man mit »Jein« beantworten. Denn schließlich startet die Login-Shell mit der Subshell schon mal einen weiteren Prozess. Und die Subshell startet mit unserem Shellscript einen oder mehrere Prozesse, also ebenfalls einen weiteren Kindprozess. Aber bedenken Sie bitte, dass ein Shellscript keine ausführbare Anwendung im eigentlichen Sinne ist, sondern eine Textdatei. Die Subshell startet gegebenenfalls weitere Prozesse, die Sie in dieser Textdatei (Ihrem Shellscript) angeben. Am besten kann man diesen Vorgang mit dem Kommando ps verdeutlichen:

# Script-Name : myscript
ps -f

Führen Sie das Shellscript myscript aus. Hier sieht die Ausgabe wie folgt aus:

you@host > ./myscript
UID        PID  PPID  C STIME TTY          TIME CMD
tot       3679  3661  0 10:52 pts/40   00:00:00 /bin/bash
tot       5980  3679  0 12:50 pts/40   00:00:00 /bin/bash
tot       5981  5980  0 12:50 pts/40   00:00:00 ps -f

Sie finden keine Spur von einem Prozess namens myscript, sondern nur vom Kommando ps –f, welches Sie im Shellscript geschrieben haben. Hier sehen Sie, dass unsere Subshell (PID 5980) den Prozess ps –f aufgerufen hat. Die Subshell ist ja schließlich auch unser Interpreter, der das Script myscript Zeile für Zeile abarbeiten soll – was hier auch mit ps –f geschieht.

Beachten Sie aber, dass diese Subshell im Gegensatz zu Ihrer Login-Shell nicht interaktiv arbeitet! Die Subshell arbeitet nur das Shellscript ab und wird anschließend gleich wieder beendet. Es gibt also nach einem interpretierten Kommando keinen Prompt, sondern es wird stur Kommando für Kommando abgearbeitet, bis sich das Shellscript beendet oder mit exit beendet wird.

1.9.2 Echte Login-Shell? 

Hier ist immer die Rede von einer Login-Shell. Da ich recht intensiv u. a. mit Linux unter einem Windowmanager (bspw. KDE) arbeite, wird vielleicht der ein oder andere leicht ergraute UNIX-Guru feststellen: Der benutzt ja gar keine echte Login-Shell. Was ist also eine Login-Shell?

Eine Login-Shell ist eine normale Shell, die als erstes Kommando (Prozess) beim Einloggen gestartet wird und beim Hochfahren der kompletten Umgebung (jede Shell hat eine Umgebung) viele andere Kommandos startet. Die Lebensdauer der Login-Shell wird meistens als Session (die Zeit, die man am Rechner eingeloggt ist) bezeichnet.

Eine echte Login-Shell erkennen Sie in der Ausgabe des Kommandos ps daran, dass sich vor dem Namen der Shell ein '–' befindet (bspw. –bash; –sh oder –ksh). Es verwirrt vielleicht ein bisschen, da es ja kein Kommando bzw. keine Shell mit –sh oder –ksh gibt. Dies ist allerdings wieder eine Eigenheit der Funktion execl() unter C, bei der eben das Argument vom Kommandonamen nicht gleich dem Argument des Dateinamens sein muss. Setzt man einen Bindestrich vor die Shell, so verhält sich die Shell eben wie eine Login-Shell. Wollen Sie die Login-Shell ändern, sollten Sie sich das Kommando chsh (Abkürzung für change shell) ansehen.

Bei der Ausgabe der Scripts im Buch konnten Sie erkennen, dass ich häufig keine echte Login-Shell verwendet habe. Wollen Sie eine echte Login-Shell ausführen, müssen Sie sich im Textmodus anmelden (unter Linux finden Sie einen echten Textmodus mit der Tastenkombination (Strg)+(Alt)+(F1) bis (F6)). Beim Anmelden im Textmodus landen Sie in einer echten Login-Shell – also einer Shell, die sich unmittelbar nach dem Anmelden öffnet.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.