2.5.8 Prozessmanagement

Übersicht über die Befehle auf dieser Seite (in fett bedeutet prüfungsrelevant):

Befehl Beispiel Beschreibung
kill kill 1234 Beendet den Prozess mit der PID 1234
pkill pkill name Beendet Prozesse anhand ihres Namens
killall killall name Beendet alle Instanzen eines bestimmten Prozesses
crontab crontab -e Öffnet den Crontab-Editor zur Planung von Aufgaben
bg bg %1 Setzt einen angehaltenen Job im Hintergrund fort
fg fg %1 Holt einen Job in den Vordergrund
jobs jobs Listet alle aktuellen Jobs auf
nohup nohup befehl & Führt einen Befehl aus, der gegen Abmeldung immun ist

Jeder ausgeführte Befehl und jedes laufende Programm führt zu einem Prozess. Prozesse sind die grundlegenden Einheiten in einem Betriebssystem. Wir haben bereits Prozesse angesehen, als wir den Befehl ps aux | grep apache verwendet haben, um laufende Apache-Prozesse zu finden. Das Prozessmanagement ist wichtig für die Kontrolle und Verwaltung eines Systems, insbesondere wenn viele Programme gleichzeitig ausgeführt werden.

Befehle "kill", "pkill" und "killall"

Der Befehl kill sendet ein Signal an einen Prozess, um ihn zu beenden.

Der Befehl pkill beendet Prozesse anhand ihres Namens.

Der Befehl killall beendet alle Instanzen eines bestimmten Prozesses. Dies ist normalerweise das, was wir benötigen.

Beispiele

  • kill 1234: Beendet den Prozess mit der PID 1234 auf normale Art.
  • kill -9 1234: Erzwingt das Beenden des Prozesses mit der PID 1234.
  • pkill apache2: Beendet alle Prozesse mit dem Namen apache2.
  • killall apache2: Beendet alle Instanzen des Prozesses apache2.

Zombies

Zombie-Prozesse sind Prozesse, die ihre Ausführung beendet haben, aber deren Prozess-ID (PID) und Eintrag in der Prozess-Tabelle noch nicht von ihrem Elternprozess freigegeben wurden. Diese Einträge bleiben bestehen, bis der Elternprozess die Rückmeldung (Exit-Status) des beendeten Prozesses abruft. Zombies verbrauchen keine CPU-Ressourcen, können aber die Anzahl der verfügbaren PIDs auf einem System reduzieren. Um Zombie-Prozesse zu entfernen, muss oft der Elternprozess beendet werden, sodass der init-Prozess (PID 1) die Kontrolle übernimmt und die Zombie-Prozesse bereinigt.

Wie viele Prozesse können unter Linux laufen?

Die maximale Anzahl an Prozessen, die auf einem Linux-System laufen können, wird durch die kernel.pid_max Einstellung im Kernel gesteuert. Diese Einstellung kann durch den Befehl cat /proc/sys/kernel/pid_max überprüft werden. In der Regel ist dieser Wert hoch genug, um die Bedürfnisse der meisten Systeme zu decken, aber er kann bei Bedarf angepasst werden. Änderungen sind im laufenden Betrieb mit sysctl -w kernel.pid_max=<Wert> möglich und werden durch einen Eintrag in /etc/sysctl.conf dauerhaft.

Befehle "crontab", "bg", "fg" und "nohup"

Prozesse können im Vordergrund oder im Hintergrund ausgeführt werden. Vordergrundprozesse blockieren das Terminal, bis sie abgeschlossen sind, während Hintergrundprozesse das Terminal nicht blockieren, sodass andere Befehle eingegeben werden können.

Vordergrund, Hintergrund und Jobs

Ein Befehl läuft normalerweise im Vordergrund. Das Terminal ist dann blockiert, bis der Befehl fertig ist. Wird ein & angehängt, läuft der Befehl im Hintergrund, und das Terminal ist sofort wieder frei. Befehle, die die Bash auf diese Weise verwaltet, heißen Jobs. Jeder Job erhält eine kleine Job-Nummer, die nur im aktuellen Terminal gilt. Die PID eines Prozesses gilt dagegen im ganzen System.

Was soll passieren? Eingabe
Befehl im Hintergrund starten befehl &
laufenden Befehl im Vordergrund abbrechen Ctrl+C
laufenden Befehl im Vordergrund anhalten Ctrl+Z
alle Jobs anzeigen (mit -l zusätzlich die PID) jobs bzw. jobs -l
Job in den Vordergrund holen fg %1
angehaltenen Job im Hintergrund fortsetzen bg %1
Job beenden kill %1

Beispiel: eine Sitzung mit zwei Jobs

$ sleep 300 &
[1] 4711
$ sleep 400
^Z
[2]+  Stopped                 sleep 400
$ jobs
[1]-  Running                 sleep 300 &
[2]+  Stopped                 sleep 400
$ bg %2
[2]+ sleep 400 &
$ jobs
[1]-  Running                 sleep 300 &
[2]+  Running                 sleep 400 &
$ kill %1
[1]-  Terminated              sleep 300
$ fg %2
sleep 400
^C

Was passiert hier?

  • sleep 300 & startet Job 1 im Hintergrund. Die Bash meldet [1] 4711, also Job-Nummer 1 und PID 4711.
  • sleep 400 läuft im Vordergrund und blockiert das Terminal. Mit Ctrl+Z wird er angehalten (Stopped) und zu Job 2. Ein angehaltener Job verbraucht keine Rechenzeit, erledigt aber auch nichts.
  • jobs zeigt beide Jobs. Das + markiert den zuletzt verwendeten Job, das - den davor. fg und bg ohne Angabe beziehen sich immer auf den Job mit +.
  • bg %2 setzt Job 2 im Hintergrund fort, er ist jetzt wieder Running.
  • kill %1 beendet Job 1.
  • fg %2 holt Job 2 in den Vordergrund. Das Terminal ist wieder blockiert, bis Ctrl+C den Befehl abbricht.

Das Prozentzeichen nicht vergessen

%1 bedeutet „Job Nummer 1“. Ohne Prozentzeichen wird die Zahl als PID verstanden. kill 1 würde also versuchen, den Prozess mit der PID 1 zu beenden, und das ist der wichtigste Prozess des ganzen Systems.

Jobs gehören zum Terminal

jobs zeigt nur die Jobs, die im aktuellen Terminal gestartet wurden. Prozesse aus anderen Terminals oder vom System sieht man nur mit ps aux. Beim Abmelden oder Schließen des Terminals werden die Jobs in der Regel beendet. Soll ein Befehl weiterlaufen, wird er mit nohup gestartet (siehe unten).

Zeitgesteuerte Aufgaben und Abmeldung

Der Befehl crontab plant Aufgaben (also Prozesse) zur Ausführung zu festgelegten Zeiten oder in regelmäßigen Intervallen.

Der Befehl bg setzt einen angehaltenen Job im Hintergrund fort.

Der Befehl fg holt einen Job in den Vordergrund.

Der Befehl nohup führt einen Befehl aus, der gegen Abmeldung immun ist. Wenn man also das Terminalfenster schließt, dann läuft der Prozess weiter.

Beispiele

  • crontab -e: Öffnet den Crontab-Editor zur Planung von Aufgaben.
  • bg %1: Setzt den Job mit der ID 1 im Hintergrund fort.
  • fg %1: Holt den Job mit der ID 1 in den Vordergrund.
  • nohup grep 'Error' /var/log/syslog > errors.txt &: Führt den Befehl grep im Hintergrund aus und leitet die Ergebnisse in die Datei errors.txt um, ohne dass der Prozess bei Abmeldung beendet wird.