Linux · Tag 3 · Kapitel 03 von 6

Prozessverwaltung

Wenn was klemmt, willst du gezielt eingreifen — nicht panisch rebooten. Heute lernst du Prozesse zu beobachten (ps, top), in den Hintergrund zu schicken (&, jobs, fg/bg), zu beenden (kill) und zu priorisieren (nice/renice).

📚 Kapitel 03 ⏱️ ca. 25 min Theorie + 45 min Lab 🧪 Lab 3.3
Inhalt dieses Kapitels
3.1

Was ist ein Prozess?

Grundlage

Ein Prozess ist ein laufendes Programm. Wenn du nano öffnest, wird aus dem Programm auf der Disk ein Prozess im RAM. Wenn du es schließt, verschwindet der Prozess. Der Kernel verwaltet alle Prozesse, weist ihnen CPU-Zeit und Speicher zu.

Jeder Prozess hat eine PID (Process ID) — eine eindeutige Nummer. PID 1 ist immer systemd (der erste Prozess nach dem Bootvorgang). Alle anderen Prozesse stammen direkt oder indirekt von PID 1 ab.

Prozess-Anatomie auf einen Blick

┌─────────────────────────────────────────────┐ │ Prozess: nano /etc/hosts │ ├─────────────────────────────────────────────┤ │ PID: 4711 (eindeutige Nummer) │ │ PPID: 3892 (Parent — wer hat mich gestartet?) │ USER: admin (wem gehört der Prozess?) │ STATE: S (R running, S sleeping, Z zombie, T stopped) │ CPU: 0.2 % │ │ MEM: 0.1 % │ │ CMD: nano /etc/hosts │ └─────────────────────────────────────────────┘
🧠
Programm vs. Prozess

Ein Programm ist eine Datei auf der Disk (/usr/bin/nano). Ein Prozess ist ein laufendes Programm im RAM. Du kannst dasselbe Programm mehrfach starten — dann gibt es mehrere Prozesse mit verschiedenen PIDs. Drei nano-Fenster offen = drei Prozesse.

🛡️
Wozu Prozesse verstehen?
  • Hängender Browser? → finden, gezielt beenden, nicht rebooten
  • Server zu langsam? → wer frisst die CPU? top zeigt's
  • Backup soll laufen, aber nicht stören: → mit nice niedriger priorisieren
  • Mehrere Sachen gleichzeitig im Terminal:& + jobs
3.2

ps — Prozess-Schnappschuss

Pflicht

ps = process status. Macht einen Schnappschuss der laufenden Prozesse. Ohne Optionen zeigt es nur die Prozesse deiner aktuellen Shell — meist enttäuschend wenig.

Die wichtigsten ps-Varianten

BefehlZeigt
psNur Prozesse der aktuellen Shell (meist 2–3)
ps -alfEmpfohlen für Admins. alle Prozesse mit Terminal, long format (zeigt PRI, NI, PPID, State), full format (volle Befehlszeile)
ps -efAlle Prozesse inkl. ohne Terminal (Daemons), Full-Format mit PPID
ps auxBSD-Stil — alternativer Klassiker, zeigt %CPU und %MEM, aber kein PRI/NI
ps -u adminNur Prozesse des Benutzers admin
ps -ef | grep nginxFilter: nur Prozesse mit „nginx" im Namen

So liest du ps -alf

Starte zur Demonstration zuerst einen Test-Prozess, den du gleich selbst beobachten kannst:

bash
# Test-Prozess starten (schläft 444 Sekunden im Hintergrund)
sleep 444 &

# Jetzt anschauen, was läuft
ps -alf | head -10

Beispiel-Ausgabe (gekürzt):

text
F S UID    PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY      TIME CMD
4 S root  3892  3891  0  80   0 -  5721 do_wai pts/0   00:00:00 -bash
0 S root  4711  3892  0  80   0 -  1234 hrtime pts/0   00:00:00 sleep 444
4 R root  4712  3892  0  80   0 -  5234 -      pts/0   00:00:00 ps -alf

Die wichtigsten Spalten — was bedeuten sie?

SpalteBedeutung
FFlags (Kernel-interne Info, meist 0, 1 oder 4 — selten relevant)
SState — R running, S sleeping (Standard), D uninterruptible (meist I/O-warten), Z zombie, T stopped
UIDWem gehört der Prozess (User-Name, falls bekannt)
PIDProcess ID — eindeutige Prozess-Nummer
PPIDParent PID — wer hat diesen Prozess gestartet? Wichtig zum Verständnis der Prozess-Hierarchie.
CCPU-Auslastung als Ganzzahl (selten interessant — bessere Werte in top)
PRIPriorität — vom Kernel berechnet. Default 80 (höher = niedrigere Priorität in dieser Anzeige!)
NINiceness — der vom User beeinflussbare Wert (-20 bis +19, Default 0). Mehr dazu in Abschnitt 3.6.
TTYAn welchem Terminal hängt der Prozess? ? = kein Terminal (Daemon), pts/0 = SSH-Terminal etc.
TIMECPU-Zeit, die der Prozess bisher verbraucht hat (nicht Echtzeit!)
CMDWelches Programm wird ausgeführt
💡
Aha-Moment: PPID = Eltern-Prozess

Im Beispiel oben hat der sleep 444-Prozess die PPID 3892 — das ist die PID deiner Bash. Bash hat sleep gestartet. Wenn du Bash schließt, geht der sleep-Prozess auch weg (es sei denn, du nutzt nohup oder disown). PPID hilft dir, Prozess-Bäume zu verstehen.

📌
Suchen nach Befehl

Der Klassiker zum Auswendiglernen: ps -ef | grep BEFEHL — findet alle Prozesse mit dem Namen, zeigt deren PID. Wenn du den PID weißt, kannst du gezielt killen (kommt in Abschnitt 3.5). Beispiel: ps -ef | grep sleep.

▶ ps aux — die BSD-Variante (alternativer Klassiker)

ps aux ist die zweite häufig gesehene Form. Sie zeigt zusätzlich %CPU und %MEM, aber dafür nicht PRI/NI/PPID. Beispiel-Ausgabe:

text
USER       PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root      4711  0.0  0.0   4936  1024 pts/0 S    09:23  0:00 sleep 444

Wann welche Variante? ps -alf für Prozess-Hierarchie und Priorität, ps aux wenn dich CPU- und RAM-Verbrauch interessieren. Du wirst beide im echten Admin-Alltag sehen.

▶ Weitere ps-Tricks für später
  • ps -ef --forest — Prozess-Baum (zeigt Eltern-Kind-Beziehungen grafisch)
  • ps -eo pid,user,pri,ni,comm — eigene Spalten-Auswahl
  • pgrep BEFEHL — kürzer: nur die PID(s) zu einem Namen
  • pidof BEFEHL — ähnlich, exakter Name-Match
3.3

top — live, was läuft

Pflicht

top ist der Live-Monitor. Während ps einen Schnappschuss zeigt, aktualisiert top sich alle 3 Sekunden. Genial, um zu sehen, was gerade jetzt die CPU oder den RAM frisst.

top starten und verstehen

bash
$ top

top - 10:23:45 up 2:23, 1 user, load average: 0.15, 0.22, 0.18
Tasks: 124 total,  1 running, 123 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.3 us,  1.1 sy,  0.0 ni, 96.5 id,  0.1 wa,  0.0 hi,  0.0 si
MiB Mem :   3934.2 total,   1234.5 free,   1421.0 used,   1278.7 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   2256.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4711 admin     20   0   19384   2104   1856 S   0.3   0.1   0:00.15 nano
 3892 admin     20   0   22884   5612   3340 S   0.0   0.1   0:00.42 bash
    1 root      20   0  173456  13892   8124 S   0.0   0.4   0:02.31 systemd

Die wichtigsten Spalten in top

top zeigt mehr Spalten als ps, und manche sind verwirrend. Hier die, die du verstehen musst:

SpalteBedeutung
PIDProcess ID — wie bei ps
USERWem gehört der Prozess
PRPriority — vom Kernel berechneter Wert (Default 20). Je kleiner, desto höhere Priorität. rt = realtime (höchste).
NINiceness — vom User setzbar (-20 bis +19, Default 0). Faustregel: PR = 20 + NI bei normalen Prozessen.
VIRTVirtual Memory — gesamter angeforderter Speicher. Oft viel mehr als physisch belegt (enthält reservierten, aber ungenutzten Speicher).
RESResident Memory — der tatsächlich im RAM belegte Speicher. Das ist der Wert, der zählt!
SHRShared Memory — mit anderen Prozessen geteilt (typisch: gemeinsame Bibliotheken). Teil von RES.
SState — wie bei ps: R running, S sleeping, D uninterruptible, Z zombie, T stopped
%CPUWie viel CPU-Zeit der Prozess gerade beansprucht (kann >100% sein bei Multi-Core!)
%MEMAnteil am gesamten RAM (basiert auf RES, nicht VIRT)
TIME+CPU-Zeit insgesamt seit Start (in Hundertstelsekunden)
COMMANDWelches Programm läuft
💡
Der häufigste Verständnis-Fehler: VIRT vs. RES

Wenn du in top siehst, dass ein Prozess 2.3G VIRT hat, heißt das nicht, dass er 2,3 GB RAM frisst. VIRT ist nur, was er angefordert hat. RES ist, was er wirklich benutzt. Schau immer auf RES, wenn du wissen willst, welcher Prozess der echte RAM-Fresser ist.

📌
PR vs. NI — warum zwei Spalten?

NI ist der „nice"-Wert, den du als User setzen kannst (mit nice oder renice, siehe Abschnitt 3.6). PR ist die daraus vom Kernel abgeleitete Echtzeit-Priorität. Default: NI=0 ergibt PR=20. Wenn du NI auf 10 setzt (höflicher), wird PR=30 (niedrigere Priorität für den Kernel).

Die wichtigsten Tasten in top

TasteWirkung
qquit — top beenden
hHilfe einblenden
Mnach Memory sortieren
Pnach CPU (Processor) sortieren — default
kkill — PID eingeben, dann Signal
rrenice — Priorität ändern
uFilter nach user
1einzelne CPU-Kerne anzeigen
💡
htop — die schönere Alternative

htop ist top mit Farben, Maus-Support, Prozess-Baum und besserer Bedienung. Auf einer Minimal-Installation muss man's installieren — das machen wir in Kapitel 04 (Paketverwaltung). Nicht standardmäßig dabei, aber jeder Admin installiert es als erstes nach dem Login.

▶ Was bedeutet "load average"?

Die drei Zahlen oben in top (z.B. 0.15, 0.22, 0.18) sind die Load-Average für die letzten 1, 5 und 15 Minuten. Grob: wie viele Prozesse warten gerade darauf, dass die CPU sie ausführt.

  • Wert < Anzahl der CPU-Kerne = entspannt
  • Wert = Anzahl Kerne = ausgelastet, aber nicht überlastet
  • Wert > Anzahl Kerne = überlastet, Prozesse warten

Auf einem 4-Kerne-Server ist load 3.5 okay, load 8.0 ist Stress.

3.4

Hintergrund-Prozesse: &, jobs, fg, bg

Pflicht Bonus

Im Terminal kannst du Befehle in den Hintergrund schicken — dein Prompt kommt sofort zurück, und du kannst gleichzeitig anderes machen, während der Befehl weiterläuft.

Mit & hängst du einen Befehl direkt an den Hintergrund. Die ausführliche Steuerung mit jobs/fg/bg zeigen wir als Bonus — Pflicht ist nur das &-Konzept.

▶ Bonus (optional) – Hintergrund-Steuerung mit jobs, fg, bg

Der Werkzeugkasten

BefehlWirkung
BEFEHL &Startet im Hintergrund, Prompt kommt sofort zurück
jobsListet deine Hintergrund-Jobs
fg %1Job 1 in den foreground holen
bg %1Gestoppten Job 1 im background weiterlaufen lassen
Strg+ZVordergrund-Prozess anhalten (stoppen, nicht beenden)
Strg+CVordergrund-Prozess beenden

Typischer Workflow

bash
# Großen Download im Hintergrund starten
wget https://example.com/big.iso &
# → [1] 5234   (Job-Nummer 1, PID 5234)

# Was läuft gerade im Hintergrund?
jobs
# → [1]+ Running    wget https://example.com/big.iso &

# Job 1 wieder in den Vordergrund holen
fg %1

# Im Vordergrund: anhalten mit Strg+Z
# → [1]+ Stopped    wget ...

# Gestoppten Job im Hintergrund weiterlaufen lassen
bg %1
# → [1]+ wget ... &
📌
Was zeigt jobs — und was nicht?

Nur die Prozesse, die du in deiner Shell gestartet hast. Nicht alle Prozesse des Systems (dafür ist ps da), nicht die Prozesse anderer User. jobs ist deine Job-Übersicht — was läuft in deiner aktuellen Shell.

▶ Was passiert, wenn ich das Terminal schließe?

Normalerweise: Hintergrund-Jobs werden mit beendet, weil sie an die Shell-Session gekoppelt sind. Wenn du das verhindern willst:

  • nohup BEFEHL & — Job überlebt Terminal-Schließen, Output landet in nohup.out
  • disown %1 — Job aus der Shell-Verantwortung entlassen
  • screen oder tmux — separate Terminal-Sessions (Profi-Werkzeug, kommt später)
3.5

kill — Prozesse beenden

Pflicht

kill klingt brutal, ist aber eigentlich nur „schick diesem Prozess ein Signal". Manche Signale beenden den Prozess, andere stoppen ihn nur kurz, wieder andere laden Konfiguration neu.

Die wichtigsten Signale

SignalNummerBedeutung
SIGTERM15höflich beenden — Prozess darf aufräumen (default!)
SIGKILL9sofort beenden — kann NICHT ignoriert werden, kein Aufräumen
SIGHUP1"Konfig neu laden" (bei vielen Services)
SIGINT2was Strg+C macht
SIGSTOP19Prozess pausieren (wie Strg+Z)
SIGCONT18pausierten Prozess fortsetzen

kill in der Praxis

bash
# Höflich beenden (default = SIGTERM)
kill 5234

# Wenn das nicht hilft: harter Schuss
kill -9 5234
# Identisch:
kill -KILL 5234
kill -SIGKILL 5234

# Mehrere auf einmal
kill 5234 5235 5236

# Per Name statt PID
pkill firefox
killall firefox

# Konfig neu laden, ohne Prozess zu beenden (z.B. nginx)
kill -HUP 5234
# Oder:
sudo systemctl reload nginx   # die saubere systemd-Variante!
⚠️
Erst kill, dann kill -9

Default-kill ist SIGTERM (15) — der Prozess kann aufräumen (Datei zumachen, RAM freigeben, „auf Wiedersehen" in Logs schreiben). Erst wenn er nicht reagiert, kill -9 (SIGKILL) — das ist der Notausschalter, der Prozess hat keine Chance mehr, etwas zu retten. Kann zu Daten-Verlust führen.

🛡️
Faustregel: kill -9 ist letzte Option
  • 1. Versuch: kill PID (SIGTERM, höflich)
  • 2. Versuch nach 5 Sekunden: kill PID nochmal
  • 3. Wenn immer noch hängt: kill -9 PID

Bei Services immer erst systemctl stop SERVICE versuchen — das ist die saubere Variante.

3.6

nice & renice — Priorität steuern

Pflicht

Jeder Prozess hat einen Niceness-Wert (NI in top) von -20 bis +19. Je „nicer" ein Prozess ist, desto höflicher tritt er anderen die CPU ab.

NICENESS-SKALA ──────────────────────────────────────────────── -20 ◄── HÖCHSTE Priorität (nur für root) │ Echtzeit-nah, "ich brauche CPU JETZT" │ 0 ◄── DEFAULT (normaler Prozess) │ +19 ◄── NIEDRIGSTE Priorität "ich warte gerne, andere zuerst"
🧠
Merksatz: "nice = höflich"

Je höher die Zahl, desto höflicher der Prozess. Höfliche Prozesse lassen andere zuerst. Ein Backup mit nice 19 stört niemanden — es läuft nur, wenn sonst nichts zu tun ist.

Negative Niceness = unhöflich = hohe Priorität. Das darf nur root, weil sonst jeder TN seine eigenen Prozesse bevorzugen würde.

Prozess MIT Niceness starten: nice

bash
# Backup mit niedriger Priorität starten (nicht störend)
nice -n 19 tar -czf backup.tar.gz /home/admin/

# Default-Niceness ist 10, wenn keine Zahl angegeben
nice tar -czf backup.tar.gz /home/admin/

# Hohe Priorität (nur als root!)
sudo nice -n -10 wichtige-rechnung.sh

Laufenden Prozess umpriorisieren: renice

bash
# Prozess mit PID 2398 auf Niceness -10 setzen
sudo renice -10 -p 2398

# Den Niceness eines Prozesses höflicher machen (15)
renice 15 -p 2398

# Alle Prozesse eines Users umpriorisieren
sudo renice 10 -u admin
⚠️
Wichtige Syntax-Regeln
  • Negative Niceness (höhere Priorität) braucht sudo
  • nice -n WERT (mit -n) vs. renice WERT (ohne -n, direkt die Zahl)
  • -p PID bei renice — sonst denkt es, du meinst einen User
🧪

Lab 3.3 — Prozesse beobachten und steuern

Selbstständig · 45 min
📧
Mail von Sandra Reuter <sandra.reuter@hanovatech.de>

Betreff: Server kriecht — kannst du mal nachschauen?

Hi Tim,

der Test-Server ist seit heute Morgen extrem langsam. Markus ist in Berlin, deshalb schreibe ich dich an.

Ich teile das in drei Schritte für dich auf:

  1. Erst Übersicht verschaffen: bau dir ein Testszenario mit ein paar gezielten Prozessen, damit du verstehst, was ps und top dir eigentlich sagen.
  2. Dann Hintergrund-Jobs üben: ich starte oft Sachen versehentlich im Vordergrund — zeig mir, wie ich sie in den Hintergrund schiebe, ohne sie neu zu starten.
  3. Zum Schluss das eigentliche Problem: ein Backup-Job frisst gerade die CPU. Beende einen Test-Prozess sauber, und zeig mir, wie du die Priorität so eines Jobs runterdrehen würdest.

Mach Snapshots, wenn du dich unsicher fühlst. Wenn du gleich nicht weiterkommst, ist der Hint-Toggle dein Freund.

— Sandra

👤
Empfehlung für dieses Lab: als root arbeiten

In diesem Lab wirst du Prozesse mit verschiedenen Prioritäten setzen — auch negative Niceness, die nur root darf. Statt ständig sudo zu tippen, melde dich einmal als root an:

bash
sudo su -

Am Ende des Labs mit exit wieder zurück zum normalen User. Achtung: als root hast du keine Sicherheitsnetze — deshalb der Snapshot vorher.

Phase 1 — Beobachten lernen mit ps -alf und top (15 min)
🎯
Deine Aufgabe

„Bevor du das echte Problem von Sandra suchst, musst du verstehen, was die Tools dir überhaupt zeigen. Bau dir ein kontrolliertes Szenario."

Starte dir ein paar sleep-Prozesse als Testszenario, in dem du selbst weißt, was läuft. Beobachte sie mit ps -alf und mit top. Am Ende sollst du einem Kollegen die Spalten PRI, NI, S und PPID erklären können — am eigenen Beispiel.

💡 Hint 1 — Wie bau ich mir Test-Prozesse?

Starte 3 sleep-Prozesse mit unterschiedlichen Zeiten im Hintergrund. Erinnerung: sleep ZEIT &.

💡 Hint 2 — Welcher ps-Befehl zeigt mir PRI und NI?

ps -alf ist die Variante, die diese Spalten enthält. Tipp: ps -alf | head zeigt nur die ersten Zeilen.

💡 Hint 3 — Wie sehe ich dasselbe live?

top zeigt dieselben Prozesse, nur ständig aktualisiert. Beende top mit q.

bash
# Drei Test-Prozesse starten
sleep 600 &
sleep 800 &
sleep 1000 &

# Mit ps anschauen
ps -alf | head

# Filter nur auf sleep
ps -alf | grep sleep

# Mit top live anschauen
top
# m drücken für Memory-Sortierung, P für CPU
# q zum Beenden

Erklärung: Die PPID aller sleep-Prozesse ist die PID deiner Bash — sie sind ihre Kinder. Der State S (sleeping) ist bei sleep normal: die Prozesse verbrauchen keine CPU, sie warten nur. PRI/NI stehen bei allen auf dem Default (80 bzw. 0), weil du noch keine Priorität geändert hast.

Phase 2 — Hintergrund-Jobs steuern: jobs, fg, bg, Strg+Z (15 min)
Bonus (optional)

Dieser Teil ist Bonus — bearbeite ihn, wenn du mit den Pflichtteilen fertig bist.

🎯
Deine Aufgabe

„Du sollst Sandra zeigen, wie sie aus einem vergessenen Vordergrund-Prozess wieder rauskommt — ohne ihn zu beenden."

Sandras zweites Problem: „Ich starte oft Sachen versehentlich im Vordergrund." Übe das: starte einen sleep im Vordergrund, halte ihn an, schiebe ihn in den Hintergrund, hole ihn zurück, beende ihn sauber.

💡 Hint 1 — Wie sehe ich, welche Jobs ich habe?

Der Befehl jobs listet die Jobs der aktuellen Shell.

💡 Hint 2 — Wie schiebe ich einen laufenden Vordergrund-Job in den Hintergrund?

Erst mit Strg+Z anhalten (suspend), dann mit bg im Hintergrund weiterlaufen lassen.

💡 Hint 3 — Und wieder zurück in den Vordergrund?

fg %JOB-NR (z. B. fg %1). Mit Strg+C kannst du den Vordergrund-Prozess dann beenden.

bash
# Vordergrund-Prozess starten
sleep 500

# Strg+Z drücken → angehalten
# [1]+  Stopped    sleep 500

# In den Hintergrund schicken
bg %1
# [1]+ sleep 500 &

# Liste der Jobs
jobs
# [1]+  Running    sleep 500 &

# Zurück in den Vordergrund
fg %1
# sleep 500

# Mit Strg+C beenden

Erklärung: Strg+Z sendet SIGSTOP (Prozess pausiert), bg/fg ändern nur, ob er im Vordergrund oder Hintergrund läuft — nicht, ob er läuft. Ein angehaltener Job verbraucht keine CPU, bis du ihn mit bg oder fg fortsetzt.

Phase 3 — Killen und Priorisieren (15 min)
🎯
Deine Aufgabe

„Das ist das eigentliche Skill-Set, das Sandra wissen will: Wie beende ich einen Prozess sauber, und wie priorisiere ich einen laufenden Job, ohne ihn neu starten zu müssen?"

Sandras drittes Problem: ein Backup-Job frisst die CPU. Beende einen deiner sleep-Test-Prozesse sauber mit kill, dann starte einen neuen und drehe seine Priorität mit renice runter — verifiziere die Änderung in top.

💡 Hint 1 — Wie finde ich die PID eines bestimmten Prozesses?

ps -ef | grep BEFEHL oder direkt pgrep BEFEHL.

💡 Hint 2 — Welches kill-Signal soll ich nutzen?

Default ist SIGTERM (15) — höflich. Reicht für sleep. kill -9 PID (SIGKILL) ist die brutale Variante, nur wenn der Prozess nicht reagiert.

💡 Hint 3 — Wie ändere ich die Priorität eines laufenden Prozesses?

renice WERT -p PID. Beispiel: renice 10 -p 4711 macht Prozess 4711 höflicher. Negative Werte (höhere Prio) gehen nur als root. Prüfen kannst du in top, Spalte NI.

bash
# Noch laufende sleeps anschauen
ps -ef | grep sleep

# Einen gezielt beenden (höflich)
kill PID-NUMMER

# Verifizieren
ps -ef | grep sleep
# (der eine ist weg)

# Neuen sleep starten und niedriger priorisieren
sleep 1000 &
# [1] 4811

# Niceness auf +10 setzen (höflicher)
renice 10 -p 4811
# 4811 (process ID) old priority 0, new priority 10

# In top verifizieren
top
# NI-Spalte für PID 4811 zeigt jetzt 10
# q zum Beenden

# Alle restlichen sleeps aufräumen
pkill sleep

Erklärung: renice ändert nur die Niceness — der Prozess läuft ungestört weiter, kein Neustart nötig. Als root könntest du auch negative Werte setzen (= höhere Priorität). pkill sleep räumt am Ende alle verbliebenen sleep-Prozesse auf einmal auf.

Sandras drei Probleme: gelöst.

Du hast jetzt das komplette Werkzeug-Set: beobachten (ps, top), steuern (jobs, fg, bg), beenden und priorisieren (kill, renice). Schreib Sandra kurz, was du gemacht hast — oder mach den Bonus, wenn du Zeit hast.

Vergiss nicht: mit exit zurück zum normalen User, falls du noch als root angemeldet bist.

🌟 Bonus für schnelle Teilnehmer
📌

Im Bonus übst du Prozess-Bäume und die echte Admin-Routine: "wer frisst mein System?"

  1. Top-5-CPU-Fresser: Liste die fünf Prozesse mit der höchsten CPU-Last auf. Tipp: ps -eo pid,user,%cpu,comm --sort=-%cpu | head -6
  2. Top-5-RAM-Fresser: Dasselbe für Speicher.
  3. Prozess-Baum: Zeige den ganzen Prozess-Baum mit ps -ef --forest | head -30. Welcher Prozess ist der Großvater von allen?
  4. Eigener Hintergrund-Prozess: Starte einen langen Schlaf-Prozess (sleep 600 &) und finde ihn mit ps -ef | grep sleep oder jobs. Notiere die PID. Beende ihn mit kill PID und prüfe mit jobs, dass er weg ist. Warum sleep statt yes oder ähnliches? sleep verbraucht keine CPU und stört die VM nicht — perfekt zum Üben.
bash
# 19) Top CPU
ps -eo pid,user,%cpu,comm --sort=-%cpu | head -6

# 20) Top RAM
ps -eo pid,user,%mem,comm --sort=-%mem | head -6

# 21) Prozess-Baum
ps -ef --forest | head -30
# Der "Großvater von allen" ist systemd (PID 1)

# 22) Langer Hintergrund-Prozess (CPU-schonend)
sleep 600 &
# → [1] 5678
ps -ef | grep sleep    # oder: jobs
kill 5678
jobs
# → [1]+  Terminated  sleep 600   (oder leer = weg)
# Höflich reicht hier — sleep hat nichts zu sichern
🎉
Lab 3.3 geschafft?

Sehr gut! Du kannst jetzt: Prozesse beobachten, in den Hintergrund schicken, priorisieren und beenden. Das ist exakt das Toolset, mit dem Admins täglich hängende Services und CPU-Fresser entschärfen. Sandra kann beruhigt weiterarbeiten — du hast den Server wieder unter Kontrolle.

3.7

Typische Anfänger-Fehler

Vorsicht
Fehler 1 — Sofort kill -9

„Geht nicht? kill -9!" Falsch. SIGKILL (-9) lässt dem Prozess keine Zeit, Dateien zu schließen, RAM freizugeben oder Datenbank-Verbindungen sauber zu trennen. Erst SIGTERM (default), dann erst -9, wenn nichts passiert.

Fehler 2 — Service mit kill statt systemctl stop

Bei Services (nginx, sshd, postgresql, ...) immer erst sudo systemctl stop SERVICE nehmen. systemd weiß, wie der Service sauber zu stoppen ist. kill ist nur die Notlösung, wenn systemd selbst hängt.

Fehler 3 — nice -10 vs. nice -n 10

Bei nice muss -n vor die Zahl, sonst interpretiert es die -10 als Niceness -10 (nicht 10). Bei renice ist es umgekehrt: dort wird die Zahl direkt geschrieben (z.B. renice 10 -p PID). Verwirrend, aber so ist es historisch gewachsen.

Fehler 4 — Falsche PID killen

Wenn ps aux | grep firefox mehrere Zeilen zeigt, ist eine davon der grep-Befehl selbst. Diese PID nicht killen — gefährlicher aber: nicht den richtigen Firefox-Prozess killen, sondern z.B. systemd-Komponenten. Tipp: pgrep firefox ist sicherer — listet nur die echten Treffer, kein grep-Müll.

🎯

Kontrollfragen zum Kapitel

Selbst-Check
  1. Was ist der Unterschied zwischen einem Programm und einem Prozess?
  2. Welcher Prozess hat immer PID 1, und warum?
  3. Was bedeutet die Spalte S in ps -alf? Und was sind die häufigsten Werte?
  4. Was ist der Unterschied zwischen VIRT und RES in top? Welcher Wert ist relevanter, wenn du wissen willst, ob ein Prozess viel RAM frisst?
  5. Welches Signal ist default bei kill PID? Was ist der Unterschied zu kill -9 PID?
  6. Du willst einen laufenden Prozess mit PID 4711 niedriger priorisieren (NI auf +10). Welcher Befehl?
  1. Ein Programm ist eine Datei auf der Disk. Ein Prozess ist ein laufendes Programm im RAM. Dasselbe Programm kann mehrfach als Prozess laufen.
  2. systemd hat PID 1, weil es der erste Prozess nach dem Kernel-Start ist und alle weiteren Prozesse von ihm abstammen (Init-Prozess).
  3. S = State (Zustand). Häufigste Werte: S sleeping (Standard — wartet), R running, D uninterruptible (meist I/O-warten), Z zombie, T stopped.
  4. VIRT ist der gesamte angeforderte Speicher (oft viel mehr als real belegt). RES ist der tatsächlich im RAM belegte Speicher. RES ist relevanter, wenn du den echten RAM-Fresser finden willst.
  5. Default ist SIGTERM (15) — der Prozess darf aufräumen. SIGKILL (9) beendet sofort ohne Aufräumen — Notlösung.
  6. renice 10 -p 4711 — die Zahl direkt (ohne -n), -p vor der PID. Positive Werte gehen ohne sudo, negative (höhere Prio) nur als root.