Druckversion | |||||||||||||||||||||
Prozesse bilden das tragende Konzept eines jeden Betriebssystems. Prozesse werden gestartet, angehalten, reaktiviert, beendet, ihre Ausgaben unterbunden usw. Alle Maßnahmen, die die Arbeit der Prozesse beeinflussen, fasst man daher unter dem Begriff der Prozesssteuerung zusammen. Die Shells tragen der Bedeutung solcher Mechanismen Rechnung, indem sie unterschiedlichste Möglichkeiten bieten, Prozessen die Richtung zu weisen. Vielleicht werden Sie nicht in jedem Fall die knappen Ausführungen der sehr komplexen Vorgänge verstehen, aber keine Bange, im weiteren Verlauf des Buches tauchen wir noch mehrfach in die Tiefen dieser Materie ab. Verfolgen Sie aufmerksam die Ausgaben der Beispiele, dann sollten Ihnen die Kommandos bg, fg, jobs und nohup ihren Zweck offenbaren.
Wenn die Festplatte kreischt, oder der Bildschirm flimmert, wenn die Soundkarte tönt oder der Prozessor sich erhitzt,... - immer dann zeichnet ein Prozess dafür verantwortlich. Programme sind die Ablaufpläne, nach denen etwas zu verrichten ist und Prozesse die Instanzen, die letztlich die Arbeit verrichten. Wann immer im System sich etwas dreht, dann ist ein Prozess am werkeln und selbst wenn der Prozessor scheinbar ruht, ist ein Prozess - der Idle-Prozess - aktiv und tut nichts anderes, als zu warten, dass sich wieder etwas tut... So ein Prozess im System steht nicht nur für sich allein, sondern ist in die Gesellschaft von seinesgleichen integriert, mit denen er auch Informationen austauschen kann. Die dabei grundlegende Beziehung ist die Eltern-Kind-Verwandtschaft zwischen einem Prozess und den von ihm erzeugten Prozessen. Der Ursprung aller Prozesse und »Prozessfamilien« liegt im init-Prozess, der als erster Prozess beim Start des Systems mit der Prozessnummer (PID) 1 ins Leben gerufen wird, und dann die elementaren Programme des Systems startet. Wenn man alle im System laufenden Prozesse auf Basis dieser Beziehung betrachtet, erhält man einen Prozessbaum. Die Hierarchie lässt sich z.B. mit dem Kommando pstree darstellen:
Was ist nun ein Prozess? Ein Stück Programm-Code, das zur Ausführung in den Hauptspeicher geladen wurde, und im System durch Parameter wie Prozessnummer (PID), Elternprozessnummer (PPID), Besitzer, Priorität, Nice-Level, Status usw. gekennzeichnet ist. Einige Parameter bringt das Kommando ps zum Vorschein:
Die PID (Prozessnummer) ist die eindeutige Kennzeichnung eines Prozesses während der Laufzeit des Systems, PPID ist die Prozessnummer seines Elternprozesses und UID (Nutzerkennung) der den Prozess startende Benutzer. Wichtig zu wissen ist, dass ein Prozess, dessen Elternprozess nicht mehr existiert, automatisch dem init-Prozess (PID=1) zugeordnet wird. Die Priorität (C) ist ein während der Laufzeit der Prozesses dynamisch bestimmter Wert, der für die Zuteilung von CPU-Zeit verwendet wird. Des Weiteren sehen wir bei der Ausgabe von »ps« die Startzeit STIME, das mit dem Prozess verbundene Terminal TTY (in obigem Beispiel sind allerdings nur Prozesse dargestellt, die keine Ausgaben auf ein Terminal tätigen; diesen Sachverhalt kennzeichnet das Fragezeichen) und den Namen der Programme, die von den Prozessen ausgeführt werden.
Wie wird nun ein Prozess ins Leben gerufen, und wie sieht sein weiterer Weg
aus? Der exec() Aufruf hat seinen Weg auch in den Funktionsumfang der in die Shell eingebauten Kommandos gefunden:
Erklärung: Im Beispiel wurde das Programm des laufenden Prozesses durch das Kommando »ls« ersetzt. Da der aktive Prozess die Shell selbst ist, wird diese beendet und nachdem nun auch »ls« seine Tätigkeit abgeschlossen hat, finden wir uns auf der Login-Konsole wieder (sofern es sich um die Login-Shell selbst handelte). fork() existiert nicht als eigenständiges Kommando. Eine Shell wird diesen Systemruf immer tätigen, um ein Programm innerhalb eines neuen Prozesses auszuführen. Eine Shell vermag (fast) beliebig viele Prozesse zu starten, jedoch wartet sie in den häufigsten Fällen auf die Terminierung des zuletzt gestarteten Prozesses:
Uns als Anwender steht es nun zu, einem Prozess zu signalisieren, dass er sich z.B. regulär beenden ([Ctrl]-[D] , ist i.A. programmabhängig) oder seine Verarbeitung abbrechen ([Ctrl]-[C]) soll:
Anmerkung: Das reguläre Beenden eines Prozesses kann auf verschiedenen Wegen erfolgen. In obigem Beispiel ist das Programm »cat« eigentlich dazu gedacht, aus einer Datei zu lesen, und beendet sich, sobald das Dateiende erreicht ist. Wird jedoch von der Standardeingabe eingelesen, und ist diese wie in diesem Fall mit der Tastatur verbunden, so muss der Nutzer dem Programm signalisieren, dass das »Dateiende« erreicht wurde. Dies erfolgt mit dem End-of-File-Zeichen (kurz EOF ), das auf der Tastatur mit der Tastenkombination [Ctrl]-[D] generiert wird. In solchen Fällen bestünde keine Möglichkeit, beliebig viele Prozesse quasi-parallel zu starten, da der soeben initiierte Prozess die Shell für weitere Eingaben blockiert. Die Lösung des Problems liegt im Verschieben des Prozesses in den Hintergrund. Dabei wird er von der Ein- und Ausgabe der Shell abgekoppelt und läuft im Hintergrund weiter, bis er sich selbst beendet, oder aber auf Grund einer notwendigen Interaktion mit dem Benutzer zum Anhalten gezwungen ist.
Jedes im Hintergrund laufende Programm wird als Job bezeichnet. Nach Beendigung der Eingabe des Kommandos mit [Enter] gibt die Bash auf der Standardfehlerausgabe eine Zeile mit Jobinformationen aus, wie am Beispiel zu erkennen ist. Diese beinhaltet in eckigen Klammern eine fortlaufende, von der Shell vergebene Jobnummer und die vom System dem Prozess zugeordnete Prozessnummer (PID). Mit dem Kommando jobs kann man Informationen über die derzeit auf einer Shell laufenden Hintergrundprozesse erlangen:
Die bisher vorgestellten Fälle betrachteten nur die Möglichkeit, Programme während einer Sitzung parallel von einer Shell aus zu starten, und im Hintergrund ablaufen zu lassen. Interessant ist aber auch der Weg, Programme auf der Shell zu starten, und diese nach dem Abmelden, sprich dem Beenden der benutzten Shell, weiter laufen zu lassen. Bisher waren in allen Beispielen die gestarteten Programme an die aufrufende Shell gebunden. So dass bei Beendigung selbiger auch die an sie gebundenen Prozesse den Aufruf zum Beenden erhalten. Um Programme von der Shell abzukoppeln, wird das Kommando nohup verwendet. Dieses schirmt das Programm vom HUP-Signal der Shell ab, so dass es nach dem Beenden der Shell unabhängig weiter laufen kann:
nohup startet das Programm nicht selbstständig im Hintergrund. So ist es
möglich, ein Programm analog zum »normalen« Vorgehen (ohne
»nohup«) zu starten, eventuell notwendige Eingaben vorzunehmen und erst im
Anschluss das Programm durch Eingaben von [Ctrl]-[Z] und nachfolgendem bg in den
Hintergrund zu schicken. Erst jetzt existiert der das Programm ausführende Prozess
tatsächlich abgenabelt von seinem Vorfahren. Und welche Möglichkeiten bleiben mir nun, um solch einen Prozess nachträglich zu beeinflussen? Eine direkte Verbindung zum Terminal wie bei fg ist nicht mehr möglich. Hier hilft nur noch eine indirekte Kommunikation über Signale, die u.a. mit dem Kommando kill übermittelt werden können:
Erklärung: Das Kommando »dd« (zum »Low-Level«-Kopieren) wird im Hintergrund gestartet. Dass es aktiv ist, bestätigt das »R« (running) in der Ausgabe des Kommandos »ps«. In einer weiteren Eingabe wird dem Prozess die Aufforderung zum Stoppen signalisiert (Signal Nr. 19). Dass es tatsächlich funktioniert hat, beweist nun das »T« (traced oder gestoppt) in der »ps«-Ausgabe. Mit dem Signal 18 schließlich wird der Prozess reaktiviert; das »R« ist wieder in der Ausgabe zu sehen. Damit unser Beispielkommando nicht für alle Zeit die Nullen in den Mülleimer befördert, brechen wir es mit dem Signal 15 (Aufforderung zum Beenden) ab. |
|||||||||||||||||||||
Korrekturen, Hinweise? |