Systeminformationen und Prozessverwaltung

Einführung

Ein laufendes Linux-System besteht aus mehr als seinen Dateien. Der Kernel verwaltet Hardware und Prozesse. Jeder Befehl läuft als Prozess mit einer Kennung, und die Shell verfolgt Prozesse im Vorder- und Hintergrund. Administratoren beobachten zunächst diesen Zustand und greifen anschließend auf den kleinstmöglichen relevanten Prozess zu.

In diesem Lab identifizieren Sie das Betriebssystem und den Kernel, interpretieren die Laufzeit und Load Averages, untersuchen Prozessbeziehungen, suchen Prozesse nach ihrem Namen, senden Beendigungssignale, üben die interaktive Jobsteuerung, interpretieren den Exit-Status, führen mit nohup einen unabhängigen Befehl aus und lesen aktuelle Kernelmeldungen.

System identifizieren und Auslastung interpretieren

In diesem Schritt identifizieren Sie den Kernel und die Distribution, prüfen, wie lange das System bereits läuft, und lernen, was Load Averages bedeuten.

Erstellen Sie ein Arbeitsverzeichnis und wechseln Sie hinein:

mkdir -p /home/labex/project/process-lab

cd /home/labex/project/process-lab

Der Befehl uname gibt Informationen zum Kernel aus. Mit den Optionen -s, -r und -m wählen Sie den Kernelnamen, die Kernelversion und die Maschinenarchitektur aus:

uname -srm

uname -a zeigt alle verfügbaren Felder in einer Zeile an:

uname -a

Der Kernel ist nicht dasselbe wie die Linux-Distribution. Lesen Sie die Metadaten der Distribution aus:

cat /etc/os-release

Achten Sie auf Felder wie NAME, VERSION und ID. Prüfen Sie anschließend die Laufzeit und die Auslastung:

uptime

Die Ausgabe enthält die aktuelle Uhrzeit, die Laufzeit des Systems, die Anzahl der angemeldeten Benutzer und drei Load Averages. Diese Mittelwerte beschreiben die ausführbare oder nicht unterbrechbare Arbeit über ungefähr 1, 5 und 15 Minuten. Sie sind keine Prozentwerte. Ihre Bedeutung hängt teilweise von der Anzahl der CPU-Kerne ab.

Zeigen Sie den kompakten Load-Eintrag des Kernels an:

cat /proc/loadavg

Die ersten drei Werte entsprechen dem Konzept der Load Average. Die nachfolgenden Felder zeigen ausführbare Tasks und die zuletzt vergebene Prozess-ID.

Speichern Sie eine kurze Systemübersicht zur späteren Verwendung:

uname -srm > system-summary.txt

uptime >> system-summary.txt

cat system-summary.txt

Die Datei sollte eine Kernelzeile und eine Zeile mit der Laufzeit enthalten.

Prozesse und Ressourcenaktivität untersuchen

In diesem Schritt untersuchen Sie Prozesskennungen, Elternbeziehungen und Zustände sowie eine Momentaufnahme der Ressourcenaktivität des Systems.

Ein Prozess ist ein laufendes Programm. Jeder Prozess besitzt eine Process ID, kurz PID. Die meisten Prozesse haben außerdem eine Parent Process ID, kurz PPID. Sie bezeichnet den Prozess, der den jeweiligen Prozess gestartet hat.

Der Befehl ps zeigt eine Momentaufnahme der Prozesse an. Wählen Sie nützliche Felder aus und sortieren Sie nach der PID:

cd /home/labex/project/process-lab

ps -eo pid,ppid,user,stat,comm --sort=pid | head -n 15

Mit der Option -e wählen Sie alle Prozesse aus, und -o legt die Spalten fest:

• PID ist die Prozesskennung.
• PPID ist die Kennung des Elternprozesses.
• USER ist der Besitzer des Prozesses.
• STAT ist der Prozesszustand einschließlich optionaler Kennzeichen.
• COMMAND ist der Name der ausführbaren Datei.

Zu den häufigen Zustandsbuchstaben gehören R für laufend, S für unterbrechbaren Schlaf, D für nicht unterbrechbaren Schlaf, T für angehalten und Z für Zombie. Ein schlafender Prozess wartet häufig einfach auf Arbeit.

Die BSD-ähnliche Form ps aux liefert zusätzlich CPU- und Speicherspalten sowie vollständige Befehlszeilen:

ps aux | head -n 10

top aktualisiert seine Anzeige bei interaktiver Verwendung fortlaufend. Der Batch-Modus erstellt eine einzelne stabile Momentaufnahme: Mit -b wählen Sie die Batch-Ausgabe, und -n 1 fordert eine Aktualisierung an.

top -b -n 1 | head -n 12

Die Kopfzeile fasst Laufzeit, Load Average, Task-Zustände, CPU-Auslastung und Speicher zusammen. Die darunterliegende Prozesstabelle hilft Ihnen, aktive Ressourcenverbraucher zu finden.

Öffnen Sie nun die interaktive Anzeige:

top

Beobachten Sie, wie sich die Werte aktualisieren, suchen Sie die Spalten %CPU und %MEM, und drücken Sie anschließend q, um zur Shell zurückzukehren. Das interaktive top eignet sich, wenn Sie Veränderungen über einen Zeitraum beobachten müssen. Der Batch-Modus ist besser geeignet, wenn die Ausgabe gespeichert oder von einem anderen Befehl verarbeitet werden soll.

Speichern Sie eine gezielte Prozessmomentaufnahme als überprüfbares Ergebnis:

ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt

head -n 5 process-snapshot.txt

Einen Übungsprozess starten und finden

In diesem Schritt starten Sie einen harmlosen Hintergrundprozess, speichern seine PID und finden ihn sowohl mit ps als auch mit pgrep.

Das abschließende & weist die Shell an, einen Befehl im Hintergrund auszuführen und sofort die Eingabeaufforderung zurückzugeben. Starten Sie einen fünf Minuten laufenden sleep-Prozess mit dem sichtbaren Namen labex-worker:

cd /home/labex/project/process-lab

bash -c 'exec -a labex-worker sleep 300' &

Der spezielle Shell-Wert $! enthält die PID des zuletzt gestarteten Hintergrundprozesses. Speichern Sie sie, bevor Sie einen weiteren Hintergrundbefehl starten:

worker_pid=$!

echo "$worker_pid" > worker.pid

Untersuchen Sie genau diesen Prozess. Mit der Option -p wählen Sie eine PID aus, und mit -o legen Sie die Felder fest:

ps -o pid,ppid,user,stat,etime,args -p "$worker_pid"

ETIME zeigt die bisherige Laufzeit an, während ARGS den sichtbaren Prozessnamen enthält. Verwenden Sie pgrep -f, um die vollständige Befehlszeile zu durchsuchen. Mit -a wird sie ebenfalls ausgegeben:

pgrep -af labex-worker

Die PID aus pgrep sollte mit dem Inhalt von worker.pid übereinstimmen. Die Suche mit einem präzisen Muster ist sicherer, als auf jeden Prozess mit einem allgemeinen Namen einzuwirken.

Prozesse mit Signalen beenden

In diesem Schritt fordern Sie zunächst eine ordnungsgemäße Beendigung mit SIGTERM an und verwenden SIGKILL nur für einen Prozess, der dieses Signal absichtlich ignoriert.

Der Befehl kill sendet ein Signal an eine PID. Ohne ausdrücklich angegebenes Signal sendet er SIGTERM, also Signal 15. SIGTERM fordert ein geordnetes Herunterfahren an und gibt dem Prozess die Möglichkeit, Aufräumarbeiten durchzuführen.

Lesen Sie die PID des Worker-Prozesses ein und senden Sie SIGTERM:

cd /home/labex/project/process-lab

worker_pid=$(cat worker.pid)

kill "$worker_pid"

sleep 1

Die folgende erwartete fehlgeschlagene ps-Abfrage bestätigt, dass der Prozess beendet wurde:

ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"

Starten Sie nun einen kontrollierten Prozess, der SIGTERM absichtlich ignoriert:

bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &

stubborn_pid=$!

echo "$stubborn_pid" > stubborn.pid

Geben Sie der neuen Shell einen Moment Zeit, um ihren Signal-Handler einzurichten:

sleep 1

Senden Sie SIGTERM, warten Sie kurz und untersuchen Sie den Prozess:

kill -TERM "$stubborn_pid"

sleep 1

ps -o pid,stat,args -p "$stubborn_pid"

Der Prozess sollte weiterhin vorhanden sein, weil dieser Übungsprozess SIGTERM ignoriert. SIGKILL, Signal 9, kann weder abgefangen noch ignoriert werden. Verwenden Sie es erst, nachdem ein ordnungsgemäßes Beendigungssignal wirkungslos geblieben ist:

kill -KILL "$stubborn_pid"

Räumen Sie den beendeten Hintergrundjob auf. Der Status ungleich null ist hier erwartet. Durch || true kann die Übungssequenz fortgesetzt werden:

wait "$stubborn_pid" 2>/dev/null || true

ps -p "$stubborn_pid" || echo "labex-stubborn required SIGKILL"

SIGKILL gibt einem Prozess keine Möglichkeit, seinen Zustand zu speichern oder Anwendungsressourcen ordnungsgemäß freizugeben. Es ist daher das letzte Mittel.

kill richtet sich an eine bekannte PID. Wenn Sie einen Prozess anhand seines Namens oder seiner vollständigen Befehlszeile auswählen müssen, kombiniert pkill die Suche mit dem Senden eines Signals. Starten Sie einen weiteren kontrollierten Prozess mit einer eindeutigen Befehlszeile:

bash -c 'exec -a labex-helper sleep 300' &

helper_pid=$!
echo "$helper_pid" > helper.pid

Bestätigen Sie die genaue Übereinstimmung mit der vollständigen Befehlszeile, bevor Sie eine Aktion ausführen:

pgrep -af '^labex-helper 300$'

Senden Sie mit pkill -f SIGTERM an genau diese Übereinstimmung. Die Anker ^ und $ verhindern, dass dieses Trainingsmuster andere Befehlszeilen erfasst:

pkill -TERM -f '^labex-helper 300$'

wait "$helper_pid" 2>/dev/null || true
ps -p "$helper_pid" || echo "labex-helper stopped by pkill"

Verwenden Sie präzise pkill-Muster und prüfen Sie die Treffer zuerst mit pgrep. Allgemeine Muster können mehr Prozesse beenden als beabsichtigt.

Jobs im Vorder- und Hintergrund steuern

In diesem Schritt halten Sie einen Vordergrundbefehl an, setzen ihn im Hintergrund fort, holen ihn wieder in den Vordergrund und unterbrechen ihn.

Die Jobsteuerung gehört zur aktuell verwendeten interaktiven Shell. Starten Sie einen Vordergrundprozess mit sleep und einem erkennbaren Namen:

cd /home/labex/project/process-lab

bash -c 'exec -a labex-job sleep 300'

Das Terminal wird nun vom Vordergrundprozess belegt. Drücken Sie Ctrl+Z. Die Shell sendet ein Stoppsignal und gibt die Eingabeaufforderung zurück.

Listen Sie die Jobs auf, die dieser Shell bekannt sind. Die Option -l enthält auch die Prozess-ID:

jobs -l

Sie sollten einen Job mit dem Status Stopped sehen. Setzen Sie Job Nummer 1 im Hintergrund fort:

bg %1

jobs -l

Der Status sollte nun Running lauten, und die Eingabeaufforderung bleibt verfügbar. Holen Sie den Job wieder in den Vordergrund:

fg %1

Drücken Sie Ctrl+C, um ein Interrupt-Signal an den Vordergrundjob zu senden. Die Eingabeaufforderung sollte zurückkehren. Prüfen Sie, dass kein Übungsjob mehr vorhanden ist:

pgrep -af labex-job || echo "No labex-job process remains"

Erstellen Sie nach Abschluss der interaktiven Sequenz eine Abschlussmarkierung:

touch job-control.done

Verwenden Sie die Jobsteuerung für Befehle, die an das aktuelle Terminal gebunden sind. Später verwenden Sie nohup für Arbeiten, die nicht von der Terminalsitzung abhängen sollen.

Exit-Status lesen und getrennte Prozesse ausführen

In diesem Schritt interpretieren Sie den Exit-Status von Befehlen und führen eine kurze Hintergrundaufgabe aus, deren Ausgabe unabhängig von der Terminalanzeige erhalten bleibt.

Jeder Befehl gibt einen ganzzahligen Status zurück. Null bedeutet Erfolg; ein Wert ungleich null weist auf irgendeine Art von Fehler hin. Die Shell-Variable $? enthält den Status des zuletzt beendeten Befehls.

Führen Sie einen erfolgreichen Befehl aus und geben Sie anschließend sofort dessen Status aus:

cd /home/labex/project/process-lab

true

echo "true status: $?"

Das Ergebnis ist 0. Führen Sie nun einen Befehl aus, der seinen Pfad nicht finden kann:

ls missing-path

Speichern Sie den Status, bevor ein weiterer Befehl $? überschreibt:

missing_status=$?

echo "missing-path status: $missing_status"

Der Wert ist ungleich null. Speichern Sie beide erwarteten Bedeutungen:

printf 'success=0\nfailure=%s\n' "$missing_status" > exit-status.txt

Der Befehl nohup sorgt dafür, dass ein Programm das Hangup-Signal des Terminals ignoriert. Das abschließende & startet das Programm im Hintergrund. Die Umleitung < /dev/null trennt die Eingabe vom Terminal. Mit > nohup.log 2>&1 werden beide Ausgabeströme in eine Protokolldatei geschrieben:

nohup bash -c 'for item in one two three; do echo "background: $item"; sleep 1; done' < /dev/null > nohup.log 2>&1 &

Speichern Sie die PID des Hintergrundprozesses und warten Sie, bis die kurze Aufgabe beendet ist:

echo $! > nohup.pid

sleep 4

cat nohup.log

Sie sollten drei Zeilen sehen, von background: one bis background: three. Bei lang laufenden Aufgaben können Sie anhand der gespeicherten PID und des Protokolls den Fortschritt untersuchen.

Aktuelle Kernelmeldungen untersuchen

In diesem Schritt untersuchen Sie den Kernel-Nachrichtenpuffer und speichern die laufende Kernelversion als stabile Referenz.

Der Kernel protokolliert Meldungen zu Systemstart, Hardware, Treibern und Laufzeitereignissen in einem Ringpuffer. dmesg liest diesen Puffer aus. Dafür sind üblicherweise Administratorrechte erforderlich:

cd /home/labex/project/process-lab

sudo dmesg | tail -n 10

Die genauen Meldungen hängen vom System und vom Zeitpunkt ab. Achten Sie auf das zeitstempelähnliche Feld sowie auf die Komponente oder das Subsystem, das die jeweilige Meldung erzeugt hat.

Die Option --level filtert nach dem Schweregrad. Zeigen Sie aktuelle Warnungen und Fehler an:

sudo dmesg --level=err,warn | tail -n 10

Keine Ausgabe bedeutet nicht, dass der Befehl fehlgeschlagen ist. Es kann bedeuten, dass der aktuelle Puffer keine Meldungen mit diesen Schweregraden enthält. Durchsuchen Sie aktuelle Meldungen nach häufigen Begriffen aus den Bereichen Speicher und Netzwerk:

sudo dmesg | grep -Ei 'disk|filesystem|network|eth' | tail -n 10

Auch hier hängen die Ergebnisse vom aktuellen System ab. Speichern Sie die von uname -r gemeldete Kernelversion:

uname -r > kernel-version.txt

cat kernel-version.txt

Kernelmeldungen sind Hinweise und keine automatischen Diagnosen. Kombinieren Sie sie mit dem Prozesszustand, Service-Logs und beobachteten Symptomen, bevor Sie eine Maßnahme festlegen.

Zusammenfassung

Sie haben ein Linux-System identifiziert, Laufzeit und Load Averages interpretiert und Prozess-IDs, Elternprozesse, Besitzer, Zustände und Ressourcenaktivität sowohl mit Momentaufnahmen als auch mit interaktiven Werkzeugen untersucht. Sie haben benannte Prozesse gestartet und gefunden, sie mit kill und pkill gezielt angesprochen, SIGTERM vor SIGKILL verwendet und die Steuerung von Vordergrund- und Hintergrundjobs geübt.

Außerdem haben Sie Exit-Status interpretiert, mit nohup und expliziter Protokollierung unabhängige Aufgaben ausgeführt und Kernelmeldungen mit dmesg untersucht. Diese Beobachtung zuerst stellenden Arbeitsweisen bilden die Grundlage für eine sichere Fehlersuche bei Prozessen und bereiten Sie auf die spätere Diagnose von Services, Logs und Netzwerken im Kurs vor.