Shell-Workshop (11)

[itari]

In diesem Workshop geht es um Prozesse.

Seit mehr als 40 Jahren können die CPUs mehrere Aufgaben (Tasks) quasi gleichzeitig bearbeiten. Man teilt den einzelnen Tasks eine wenig Rechenzeit zu und unterbricht sie dann, um eine andere Task auszuführen (Mulit-Tasking, Time-Sharing). Aus der Sicht eines Prozessors sind es Tasks; aus der Sicht eines Programms, welches von der CPU (Central Processing Unit) ausgeführt wird, ist es ein 'Prozess' (process). Sie bezeichnen gemeinhin ungefähr dasselbe.

Unix/Linux ist als Multi-Tasking-System konzipiert worden, deswegen spielen Prozesse ein wichtige Rolle. Weil das so ist, wird sehr intensiv von diese Konzept gebrauch gemacht. D.h. zu Lösung einer Anwendungsaufgabe werden oft viele Prozesse gestartet, statt alles in einem Prozess irgendwie unterzubringen. Und man verwendet zur Lösung lieber viele kleine allgemeine Tools als ein großes Tool. Die Shell besitzt deswegen viele Konzepte, diese Multi-Tasking voll auszuschöpfen; man denke an das Aneinanderreihen von Kommandos und die Möglichkeit Daten zu Pipen. Weil das alles irgendwie ein Konzept ist, lebt es davon, dass sich die Leute dran halten. Zum Beispiel gibt es das KISS-Prinzip: "keep it small and simple" oder das Prinzip: "alles ist ein Datenstrom" oder das Prinzip: "denke immer in einer Hierarchie, wenn du etwas ordnen willst".

Wenn ein Linux-System mit der Boot-Phase fertig ist, dann gibt es einen Ahnvater aller Prozesse: den Init-Prozess mit der Prozessnummer '1' (man sagt eher selten zum Init 'root'-Prozess). Alle weiteren Prozesse sind seine Kind-Prozesse (child-processes) und er kann diese steuern. Er umgekehrt heißt Eltern-Prozess (parent-process). Jeder Prozess hat eine Prozessnummer, die process id (PID). Die Eltern-Prozess-Nummer wäre dann die parent process id (PPID).

Jeder Prozess kann einen neuen Prozess erzeugen, indem er sich dupliziert bzw. gabelt (fork) und die Kopie im Prozess-Scheduler (Prozess-Warteschlagen-Verwalter) aufnehmen lässt und dann als erste Aufgabe übergibt: 'lad dir ein neues Programm von der Platte' (exec). Weil sozusagen immer erst einmal alles kopiert wird, sind auch alle Einstellungen, wie Environment (set) oder geöffnete Dateien (stdin, stdout, stderror usw.) vorhanden. Ob sie durch den 'exec' dann überschrieben werden oder weiterhin benutzt werden, kann sich also ein Programmierer überlegen oder eben jemand, der ein Shell-Skript schreibt, denn dass ist ja auch nichts anderes als ein neuer Shell-Aufruf verbunden mit der Aufgabe, jetzt die Kommandos des Skriptes abzuarbeiten.

Eine nicht sonderlich hübsche Liste aller Prozesse erhält man mit dem in der BusyBox vorhandenen Kommando 'ps' (ich kürze mal die Liste ein wenig):

Syno> ps
  PID  Uid     VmSize Stat Command
    1 root        272 S   init
...........
 6706 root        544 S   /usr/sbin/inetd
...........
20351 root        236 S   telnetd
20354 root        356 S   -ash
20424 root        656 R   ps

Es wird angezeigt:
- PID: Prozess-Nummer
- Uid: welche Benutzerrechte der Prozess hat
- VmSize: die virtuelle Speichergröße in Bytes
- Stat: der aktuelle Status des Prozesses (S=sleeping R=running, W=waiting)
- Command: die ersten 80 Stellen der Kommando-Aufrufs mit Parametern

Leider kann man auch mittels Optionen nicht viel mehr heraus zaubern.

Viel hübscher in der Anzeige ist der ipkg-ps (ipkg install procps) - auch hier gekürzt:

Syno> /opt/bin/ps -el
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0     1     0  0  76   0 -   845 wait   ?        00:00:27 init
5 S     0  6706     1  0  76   0 -  1200 select ?        00:00:00 inetd
4 S     0 20351  6706  0  75   0 -   845 select ?        00:00:00 telnetd
4 S     0 20354 20351  0  75   0 -   846 wait   ttyp0    00:00:00 ash
0 R     0 20491 20354  0  77   0 -   476 -      ttyp0    00:00:00 ps

Man sieht zusätzlich die PPID und die PRIorität und anderes (siehe Manual ps). Man sieht jetzt sehr hübsch, wie die Prozesshierarchie bis zur Ausführung des 'ps' aussieht:

init -> inetd -> telnetd -> ash -> ps

Wer mit dem ssh statt mit dem Telnet arbeitet, sieht analog ähnliche Abhängigkeiten.

Man kann sich auch die zur Zeit meist beschäftigtsten Prozesse mit 'top' anschauen. Dran denken, dass man mit 'q' (für quit) den top wieder verlassen kann.

Es gibt ein Kommando, welches nicht wirklich etwas tut, sondern einfach wartet: 'sleep'. Man gibt als Option die Anzahl der Sekunden an, also sleep 300 steht für 'Warte 5 Minuten'.

Man kann - und wir werden das in einem späteren Workshop noch vertiefen - Kommandos von der interaktiven Eingabe sozusagen in den Hintergrund schieben, damit man auch weiterhin direkt mit der Shell kommunizieren kann. Das geschieht mit dem '&'-Operator:

Syno> sleep 300 &
Syno> ps
  PID  Uid     VmSize Stat Command
    1 root        272 S   init
...
 6706 root        544 S   /usr/sbin/inetd
...
20351 root        236 S   telnetd
20354 root        360 S   -ash
20498 root        192 S   sleep 300
20499 root        656 R   ps
Syno>

Der Prozess mit der PID '20498' wird also 5 Minuten 'nichts' tun, aber existieren. Natürlich kann der sleep auch ein Backup-Job per rsync oder ein Download per wget oder oder sein ... Falls es irgendwann einmal pressiert, dass man einen solchen Prozess gerne vorzeitig beenden möchte, dann kann man dem Prozess ein Signal mit der Kommando 'kill' zusenden und wenn dann der Prozess wieder zur Ausführung gebracht wird (time-sharing), wird er auf das Signal reagieren. Das Signal '9' bedeutet 'unbedingter Abbruch':

Syno> sleep 300 &
Syno> ps
....
20518 root        192 S   sleep 300
20519 root        656 R   ps
Syno> kill -9 20518
Syno> ps
....
20520 root        656 R   ps
[1] + Killed                     sleep 300

=======

Viel Spaß beim Prozessieren und Killen.

Itari


=========================================
Sinnvollerweise sind die Shell-Workshops aufeinander aufgebaut.

Shell-Workshop (10)
Shell-Workshop (12)