VMware ESXi and vSphere Cluster Management

Linux-Prozesse mit kill beenden und steuern

Lerne, wie du Linux-Prozesse mit kill, SIGTERM und SIGKILL sicher beendest, PIDs ermittelst, Prozesse pausierst und typische Fehler analysierst.

Mit dem Linux-Befehl kill lassen sich laufende Prozesse gezielt steuern. Trotz seines Namens beendet kill einen Prozess nicht zwingend sofort: Der Befehl sendet zunächst ein Signal, also eine Betriebssystemnachricht, an eine Prozess-ID.

In dieser Lektion lernst du, wie du eine PID sicher ermittelst, zunächst eine reguläre Beendigung anforderst und nur bei Bedarf zu einem härteren Signal wechselst. Außerdem geht es um Prozessrechte, top, wichtige Signale, pausierte Prozesse sowie die Grenzen von kill.

Grundprinzip von kill: Ein Signal an eine PID senden

Ein Prozess ist eine ausgeführte Instanz eines Programms. Linux weist jedem laufenden Prozess eine numerische Prozess-ID zu, kurz PID. Über diese PID kann ein Benutzer oder das Betriebssystem den Prozess gezielt ansprechen.

Ein Signal ist eine Nachricht des Betriebssystems an einen Prozess. Je nach Signal kann die Nachricht beispielsweise eine Beendigung anfordern, eine Konfigurationsdatei neu einlesen lassen, den Prozess anhalten oder seine Ausführung fortsetzen.

Der Prozess kann viele Signale selbst verarbeiten. Bei SIGTERM kann ein Programm zum Beispiel offene Dateien schließen, Daten speichern und anschließend regulär beenden. Das Signal bedeutet also zunächst: „Beende dich kontrolliert.“ Ob und wie schnell der Prozess darauf reagiert, hängt vom Programm und seinem aktuellen Zustand ab.

Einige Signale sind besondere Ausnahmen. SIGKILL und SIGSTOP können weder abgefangen noch ignoriert werden. Bei SIGKILL beendet der Kernel den Prozess, ohne dessen eigene Aufräumlogik auszuführen.

Die PID des Zielprozesses ermitteln

Bevor du ein Signal sendest, musst du das Ziel eindeutig identifizieren. Eine falsche PID kann zu Datenverlust, einem Abbruch des falschen Programms oder einer Unterbrechung eines wichtigen Dienstes führen. Prüfe deshalb möglichst den Prozessnamen, den Benutzer, die Startzeit und die vollständige Kommandozeile.

Prozesse interaktiv mit top finden

top zeigt laufende Prozesse und wichtige Systemwerte wie CPU- und Speichernutzung an:

top

In der Prozessliste findest du typischerweise Spalten wie PID, USER, PR, %CPU, %MEM und COMMAND. Eine hohe CPU-Auslastung kann auf einen problematischen Prozess hinweisen, ist aber nicht automatisch ein Fehler. Ein Compiler, eine Datenbankabfrage oder eine geplante Berechnung darf vorübergehend viel CPU verwenden.

Notiere die PID und überprüfe sie anschließend mit einer detaillierteren Abfrage. Mit q verlässt du top.

Prozessinformationen mit ps prüfen

Mit ps kannst du die Identität eines Prozesses gezielt kontrollieren:

ps -fp 13203

Die Option -f zeigt eine ausführlichere Darstellung. Dabei sind unter anderem Benutzer, Elternprozess und Kommandozeile sichtbar. Eine weitere nützliche Abfrage zeigt PID, Zustand und Kommando:

ps -o pid,state,cmd -p 13203

Die vollständige Kommandozeile ist besonders wichtig, wenn mehrere Prozesse denselben Programmnamen verwenden. Prüfe außerdem, ob der Prozess zwischenzeitlich beendet wurde. Eine PID kann später von einem anderen Prozess wiederverwendet werden.

Gezielte Suche mit pgrep und pidof

pgrep sucht Prozesse anhand ihres Namens. Mit -a werden zusätzlich die Kommandozeilen ausgegeben:

pgrep -a dd

Bei mehreren Treffern darfst du nicht einfach alle gefundenen PIDs beenden. Vergleiche Benutzer, Argumente und Zweck der einzelnen Prozesse:

ps -fp 13203

pidof liefert die PIDs eines Programms, sofern der Programmname passend bekannt ist:

pidof programmname

Auch hier gilt: Ein Name allein identifiziert nicht immer genau den gewünschten Prozess. Verwende die Ausgabe nur als Ausgangspunkt und prüfe das Ziel vor dem Signalisieren.

kill-Syntax und Standardsignal

Die grundlegende Syntax lautet:

kill PID

Ohne explizite Signalangabe sendet kill normalerweise SIGTERM. Dieses Signal fordert eine kontrollierte Beendigung an:

kill 13203

Das Standardsignal kann ausdrücklich angegeben werden. Diese Schreibweisen bedeuten dasselbe:

kill -TERM 13203
kill -SIGTERM 13203
kill -15 13203

Signalnamen sind in Skripten und bei manueller Arbeit meist lesbarer als Nummern. Außerdem können Nummern einzelner Signale je nach Architektur variieren. Informiere dich mit kill -l über die auf deinem System bekannten Signale:

kill -l

Die genaue Ausgabe und die Nummern sind von Betriebssystem und Architektur abhängig. Verwende deshalb bevorzugt Namen wie TERM, KILL, STOP oder CONT.

Wichtige Signale im Überblick

SIGHUP: Terminal-Trennung und Konfiguration

SIGHUP steht historisch mit dem Auflegen einer Terminalverbindung in Verbindung. Bei interaktiven Programmen kann eine getrennte Shell oder Terminalverbindung dieses Signal auslösen.

Viele Daemons, also dauerhaft im Hintergrund laufende Dienste, verwenden SIGHUP als Aufforderung, ihre Konfiguration erneut zu lesen. Das ist jedoch keine allgemeine Regel. Sende SIGHUP an einen Dienst nur, wenn dessen Dokumentation dieses Verhalten bestätigt. Bei systemd-Diensten ist eine dokumentierte Aktion wie systemctl reload oft die bessere Wahl.

SIGTERM: die freundliche Beendigungsanfrage

SIGTERM ist das Standardsignal von kill. Ein Programm kann darauf reagieren und kontrolliert aufräumen. Dazu gehören beispielsweise das Schließen von Dateien, das Freigeben von Ressourcen, das Schreiben von Statusdaten oder das Beenden laufender Transaktionen.

SIGKILL: nur als letzte Option

SIGKILL kann nicht abgefangen, blockiert oder ignoriert werden. Der Prozess erhält keine Gelegenheit, eigene Aufräumroutinen auszuführen:

kill -KILL 13203
kill -SIGKILL 13203

Dadurch können unvollständige Schreibvorgänge, temporäre Dateien oder inkonsistente Anwendungsdaten zurückbleiben. Verwende SIGKILL daher erst, wenn SIGTERM wirkungslos bleibt und du die möglichen Folgen akzeptierst.

SIGSTOP und SIGCONT: Prozesse pausieren

Mit SIGSTOP hältst du einen Prozess an. Das Signal ist nicht abfangbar:

kill -STOP 13203
ps -o pid,state,cmd -p 13203

Der Prozess bleibt vorhanden, führt aber vorübergehend keinen normalen Code aus. Mit SIGCONT setzt du ihn fort:

kill -CONT 13203

Ein angehaltener Prozess ist nicht beendet. Bei einem produktiven Dienst kann das Anhalten ebenso störend sein wie ein Absturz.

Sichere Eskalationsstrategie

Arbeite beim Beenden eines Prozesses in klaren Schritten:

1. Ziel prüfen: Ermittle die PID und kontrolliere Prozessname, Benutzer, Kommandozeile und möglichst den Zweck des Prozesses.
2. SIGTERM senden: Verwende kill PID oder ausdrücklich kill -TERM PID.
3. Zeit geben: Warte kurz, damit das Programm Daten speichern und Ressourcen freigeben kann.
4. Existenz prüfen: Frage mit ps -p PID oder einer anderen Prozessabfrage nach, ob die PID noch vorhanden ist.
5. SIGKILL nur bei Bedarf: Wenn der Prozess weiterläuft und die Risiken akzeptabel sind, verwende kill -KILL PID.
6. Ergebnis kontrollieren: Prüfe erneut die Prozessliste, die Systemauslastung und gegebenenfalls Protokolle.

Wichtig: Ein erfolgreich ausgeführter kill-Befehl bedeutet zunächst nur, dass das Signal gesendet wurde. Er beweist nicht, dass der Prozess bereits beendet ist.

Praktisches Beispiel: CPU-intensiven Prozess regulär beenden

Angenommen, top zeigt einen Prozess mit auffällig hoher CPU-Auslastung. Die PID lautet in diesem Beispiel 13203.

1. Starte die Überwachung:

top

2. Prüfe nach dem Ablesen der PID Besitzer und Kommandozeile:

ps -fp 13203

3. Fordere eine reguläre Beendigung an:

kill 13203

4. Kontrolliere, ob der Prozess noch existiert:

ps -p 13203

Wenn keine Prozesszeile mehr erscheint, wurde der Prozess beendet. Prüfe bei Bedarf erneut mit top, ob sich die CPU-Auslastung normalisiert hat.

Praktisches Beispiel: nicht reagierenden Prozess eskalieren

Ein nicht reagierendes Programm sollte zunächst ebenfalls regulär beendet werden:

kill -SIGTERM 13203
ps -p 13203

Warte abhängig von der Anwendung angemessen lange. Ein Programm kann wegen laufender Dateivorgänge, Datenbanktransaktionen oder umfangreicher Aufräumarbeiten einige Zeit benötigen.

Bleibt der Prozess ohne nachvollziehbaren Grund bestehen, kannst du als letzte Eskalationsstufe ein nicht abfangbares Signal senden:

kill -SIGKILL 13203
ps -p 13203

Behandle die Anwendung anschließend wie nach einem Absturz: Prüfe Datenintegrität, Protokolle und gegebenenfalls temporäre Dateien.

Prozess anhand seines Namens suchen

Für eine Namenssuche eignet sich pgrep:

pgrep -a dd

Wenn mehrere Prozesse gefunden werden, kontrollierst du jeden relevanten Treffer einzeln:

ps -fp 13203

Erst danach signalisierst du die gewünschte PID:

kill -TERM 13203

Vermeide unpräzise Aktionen gegen einen bloßen Namen, wenn mehrere Instanzen, Benutzer oder unterschiedliche Kommandozeilen vorhanden sind.

Berechtigungen und Prozesseigentümerschaft

Der Prozesseigentümer ist das Benutzerkonto, unter dem ein Prozess läuft. Ein normaler Benutzer darf in der Regel nur eigene Prozesse signalisieren. Für fremde Prozesse oder Systemprozesse fehlen normalerweise die erforderlichen Rechte.

Prüfe den Eigentümer mit:

ps -fp 13203

Falls das Signalisieren berechtigt und fachlich notwendig ist, kannst du erhöhte Rechte verwenden:

sudo kill -TERM 13203

Sei bei Prozessen von root, bei Systemdiensten und bei sicherheitsrelevanten Programmen besonders vorsichtig. Das Beenden eines kritischen Prozesses kann Sitzungen trennen, Datenbankoperationen unterbrechen oder das System destabilisieren.

Wann systemctl statt kill sinnvoller ist

Ein systemd-Dienst wird nicht nur durch eine einzelne PID definiert. Der Dienstmanager kennt Abhängigkeiten, Startreihenfolge, Neustartregeln und den gewünschten Dienstzustand. Deshalb solltest du einen solchen Dienst bevorzugt über systemctl verwalten.

systemctl status nginx
sudo systemctl stop nginx

Bei einer Konfigurationsänderung ist häufig ein Reload vorgesehen:

sudo systemctl reload nginx

Ein direktes SIGHUP ist nur dann angebracht, wenn die verwendete Software dieses Signal dokumentiert unterstützt. Ein direkter kill kann den Dienstmanager übergehen und zu einem unerwarteten Neustart oder einem falschen Status führen.

Grenzen von kill

Prozesse im Zustand D

Ein Prozess im Zustand D befindet sich im ununterbrechbaren Schlaf. Häufig wartet er auf eine blockierte Kernel- oder Ein-/Ausgabeoperation, etwa auf ein Speichergerät, ein Netzwerkdateisystem oder ein anderes Gerät.

Solange diese Kerneloperation nicht zurückkehrt, kann der Prozess auch auf SIGKILL nicht sofort verschwinden. Untersuche den Zustand beispielsweise so:

ps -o pid,state,cmd -p 13203

Bei einem D-Zustand liegt die eigentliche Ursache meist unterhalb der Anwendung: bei Speicher, Netzwerk, Treibern oder Geräten. Je nach Ursache kann eine Reparatur der Infrastruktur oder ein Neustart erforderlich sein.

Zombie-Prozesse

Ein Zombie-Prozess ist bereits beendet. Sein Elternprozess hat lediglich den Beendigungsstatus noch nicht abgeholt. Der Zombie führt keinen Programmcode mehr aus und kann deshalb nicht durch ein weiteres kill beendet werden.

Untersuche PID, Zustand und Elternprozess:

ps -o pid,ppid,state,cmd -p 13203

Die Lösung besteht darin, den Elternprozess beziehungsweise dessen Fehler zu behandeln, damit er den Status des Kindprozesses einsammelt. Das direkte Signalisieren des Zombies selbst beseitigt ihn nicht.

Entscheidungshilfe zum Beenden eines Prozesses

Typische Fehlermeldungen und Lösungen

„Operation not permitted“

Diese Meldung bedeutet meist, dass der Prozess einem anderen Benutzer gehört oder administrative Rechte erforderlich sind. Prüfe zuerst den Eigentümer:

ps -fp 13203

Wenn die Aktion fachlich und organisatorisch erlaubt ist, verwende sudo:

sudo kill -TERM 13203

Bei Systemprozessen musst du vorab die Auswirkungen bewerten.

„No such process“

Die PID ist möglicherweise falsch, der Prozess wurde bereits beendet oder die PID wurde aus einer veralteten Anzeige übernommen. Frage die Prozessliste erneut ab und kontrolliere vor dem Signal Besitzer und Kommandozeile:

ps -p 13203
pgrep -a programmname

Der Prozess läuft nach SIGTERM weiter

Das Programm kann SIGTERM langsam verarbeiten, anders behandeln oder auf eine blockierte Operation warten. Warte zunächst angemessen und untersuche den Status:

ps -o pid,state,cmd -p 13203

Erst wenn SIGTERM wirkungslos bleibt und die Folgen akzeptiert werden, ist SIGKILL eine mögliche letzte Option.

Der Prozess bleibt nach SIGKILL sichtbar

Prüfe, ob der Prozess den Zustand D hat oder ein Zombie ist:

ps -o pid,ppid,state,cmd -p 13203

Bei D muss die blockierte Ein-/Ausgabeursache untersucht werden. Bei einem Zombie musst du den Elternprozess behandeln.

Nach dem Beenden treten Datenfehler auf

Wahrscheinliche Ursachen sind ein erzwungener Abbruch während eines Schreibvorgangs oder fehlende Aufräumarbeiten. Prüfe Anwendungsprotokolle und Datenintegrität. Verwende künftig zuerst SIGTERM und bei Diensten den vorgesehenen stop- oder reload-Mechanismus.

Prüfungsrelevante Merksätze

• kill sendet ein Signal; der Name bedeutet nicht automatisch sofortiges Beenden.
• Eine PID identifiziert einen laufenden Prozess, kann aber nach dessen Ende wiederverwendet werden.
• kill PID sendet normalerweise SIGTERM.
• SIGTERM ist die bevorzugte reguläre Beendigungsanfrage.
• SIGKILL ist nicht abfangbar und verhindert Aufräumarbeiten des Programms.
• SIGSTOP hält an, SIGCONT setzt fort.
• Prozesse im Zustand D können trotz SIGKILL sichtbar bleiben.
• Zombie-Prozesse sind bereits beendet und müssen vom Elternprozess eingesammelt werden.
• Für systemd-Dienste ist systemctl meist geeigneter als ein direktes Signalisieren einer PID.

Eine sichere Kurzform lautet: PID ermitteln, Ziel verifizieren, SIGTERM senden, Ergebnis prüfen und SIGKILL nur als letzte Eskalationsstufe verwenden.