Linux Deutsch

Linux-Prozesse mit kill und Signalen beenden, stoppen und fortsetzen

Lernen Sie, Linux-Prozesse mit kill und Signalen sicher zu beenden, anzuhalten und fortzusetzen. Mit SIGTERM, SIGKILL, top, ps, Berechtigungen und Praxisbeispielen.

Der Befehl kill dient unter Linux nicht ausschließlich zum Beenden von Prozessen. Er sendet ein Signal an eine oder mehrere Prozess-IDs. Ein Signal ist eine vom Kernel zugestellte Benachrichtigung oder Steueranweisung. Je nach Signal kann ein Prozess kontrolliert beendet, sofort beendet, angehalten oder fortgesetzt werden.

Diese Lektion zeigt einen sicheren Ablauf: Prozess identifizieren, PID und Besitzer prüfen, zunächst SIGTERM senden, den Zustand kontrollieren und nur bei Bedarf eskalieren.

Grundidee von kill und Signalen

Ein Prozess ist eine laufende Instanz eines Programms. Der Kernel weist jedem laufenden Prozess eine PID zu. PID steht für Process ID und ist die Kennung, über die ein Signal normalerweise zugestellt wird.

Die Grundsyntax lautet:

kill [Signal] PID

Wird kein Signal angegeben, verwendet kill standardmäßig SIGTERM. Der Name des Befehls ist daher verkürzt: kill bedeutet technisch „ein Signal an einen Prozess senden“.

Prozesse können Signale unterschiedlich verarbeiten. Viele Signale kann ein Programm abfangen und beispielsweise Aufräumarbeiten ausführen. Manche Signale können ignoriert oder blockiert werden. SIGKILL und SIGSTOP bilden wichtige Ausnahmen: Sie können vom Prozess weder abgefangen noch ignoriert werden.

Die PID eines Prozesses ermitteln

Prozesse mit top beobachten

top zeigt laufende Prozesse sowie deren CPU- und Speichernutzung interaktiv an:

top

Prüfen Sie in der Ausgabe nicht nur die PID. Vergleichen Sie mindestens den Prozessnamen, den Benutzer und die CPU-Auslastung. Dadurch sinkt das Risiko, versehentlich eine andere Instanz desselben Programms zu signalisieren. Mit der Taste q verlassen Sie top.

Alternative Suchbefehle

Für eine gezielte Suche eignen sich unter anderem:

ps -ef | grep '[d]d'
pgrep -a dd
htop

ps listet Prozesse in einem bestimmten Format auf. Das Muster '[d]d' verhindert, dass sich der Suchbefehl selbst als Treffer anzeigt. pgrep -a gibt passende PIDs zusammen mit der vollständigen Kommandozeile aus. htop ist eine interaktive Alternative zu top, sofern es installiert ist.

Vor dem Senden eines Signals können Sie eine PID ausführlich prüfen:

ps -p 13203 -o pid,ppid,user,stat,etime,cmd

Die Ausgabe enthält unter anderem die PID, den Elternprozess, den Besitzer, den Status, die Laufzeit und die Kommandozeile. Verwenden Sie keine PID aus einer lange zurückliegenden Ausgabe: PIDs können nach dem Ende eines Prozesses später wiederverwendet werden.

SIGTERM: der normale erste Versuch

Der Befehl ohne Signalangabe sendet SIGTERM:

kill 13203

Die ausdrückliche Schreibweise ist oft verständlicher:

kill -TERM 13203

SIGTERM ist eine reguläre Aufforderung zur Beendigung. Ein Programm kann darauf reagieren, offene Dateien schließen, temporäre Daten verarbeiten, Zustände speichern und andere Aufräumarbeiten durchführen. Das konkrete Verhalten hängt vom Programm ab.

Warten Sie nach dem Signal kurz und prüfen Sie anschließend, ob die PID noch existiert:

ps -p 13203 -o pid,ppid,user,stat,etime,cmd

Bei einem Dienst sollten Sie zusätzlich Protokolle und den Dienststatus kontrollieren. Ein Prozess kann während seiner Aufräumarbeiten noch kurze Zeit sichtbar sein.

SIGKILL: erzwungenes Beenden als Eskalation

Wenn ein Prozess auf SIGTERM nicht reagiert und ein erzwungenes Ende vertretbar ist, können Sie SIGKILL verwenden:

kill -KILL 13203

SIGKILL beendet den Prozess unmittelbar durch den Kernel. Der Prozess kann dieses Signal nicht abfangen, blockieren oder ignorieren. Deshalb erhält er keine Gelegenheit, reguläre Aufräumroutinen auszuführen.

Die häufige Kurzform ist:

kill -9 13203

Die numerische Schreibweise funktioniert auf vielen Linux-Systemen, ist aber weniger lesbar. kill -KILL macht die Absicht deutlich.

Wichtige weitere Signale

SignalnameTypische NummerWirkungAbfangbar oder ignorierbar?Typischer Einsatz
SIGHUP1Historisch: Verlust des Kontrollterminals; bei vielen Diensten Aufforderung zum Neuladen der KonfigurationProgrammabhängigKonfiguration neu einlesen, sofern unterstützt
SIGTERM15Reguläre BeendigungsanfrageÜblicherweise jaErster Versuch beim Beenden
SIGKILL9Sofortige Beendigung durch den KernelNeinLetzter Ausweg
SIGSTOPplattformabhängigProzess sofort anhaltenNeinVorübergehend anhalten
SIGCONTplattformabhängigAngehaltenen Prozess fortsetzenNicht als Stop-Signal behandeltNach SIGSTOP fortsetzen

Signalnummern können sich zwischen Unix- und Linux-Architekturen teilweise unterscheiden. Signalnamen sind deshalb lesbarer und portabler. Mit kill -l sehen Sie die auf dem aktuellen System bekannten Signale:

kill -l

SIGHUP und Konfigurationsneuladen

SIGHUP steht historisch mit dem Verlust eines Kontrollterminals in Verbindung. Viele Hintergrunddienste verwenden es zusätzlich als Aufforderung, Konfigurationsdateien neu einzulesen:

kill -HUP 13203

Das ist kein allgemeines Verhalten. Prüfen Sie zuerst die Dokumentation des konkreten Programms und kontrollieren Sie anschließend Logs und Status.

SIGSTOP und SIGCONT

Mit SIGSTOP halten Sie einen Prozess an, ohne ihn zu beenden:

kill -STOP 13203

Mit SIGCONT setzen Sie ihn fort:

kill -CONT 13203

Kontrollieren Sie danach, ob der Prozess wieder CPU-Zeit erhält oder seine Arbeit fortsetzt.

Signalangaben und mehrere PIDs

Signale können mit dem vollständigen Namen, ohne das Präfix SIG oder als Nummer angegeben werden:

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

Die Variante mit Namen ist in Skripten meist verständlicher. Mehrere PIDs können in einem Aufruf angegeben werden:

kill -TERM 13203 13204 13205

In Skripten sollten Sie den Rückgabestatus prüfen. Ein Status ungleich null weist typischerweise darauf hin, dass mindestens ein Signal nicht zugestellt werden konnte:

if kill -TERM 13203; then
    echo "Signal wurde zugestellt"
else
    echo "Signal konnte nicht zugestellt werden"
fi

Eine erfolgreiche Rückgabe bedeutet, dass der Kernel die Zustellung akzeptiert hat. Sie bedeutet nicht zwingend, dass der Prozess bereits beendet ist.

Sicherer Praxisablauf bei einem hängenden Prozess

  1. Identifizieren: Suchen Sie den Prozess mit top, ps, pgrep oder htop.
  2. Prüfen: Vergleichen Sie PID, Prozessname, vollständige Kommandozeile, Benutzer, CPU-Auslastung und mögliche Abhängigkeiten.
  3. Besitzverhältnisse bewerten: Klären Sie, ob der Prozess Ihnen gehört und welche Anwendung oder welcher Dienst davon abhängt.
  4. SIGTERM senden: Verwenden Sie zunächst kill -TERM PID.
  5. Status kontrollieren: Prüfen Sie mit ps, top, Logs oder dem Dienststatus, ob der Prozess verschwunden ist oder beendet wird.
  6. Eskalieren: Verwenden Sie nur bei Bedarf und vertretbarem Risiko kill -KILL PID.
  7. Nachkontrolle: Untersuchen Sie abhängige Dienste, offene Aufgaben, Dateien und Systemressourcen.

Beispiel: ressourcenintensives dd

Nehmen wir an, ein Prozess namens dd verursacht ungewöhnlich hohe CPU-Auslastung. Suchen Sie ihn zunächst:

pgrep -a dd
ps -ef | grep '[d]d'

Prüfen Sie die gefundene PID nochmals mit Benutzer und Kommandozeile. Angenommen, die korrekte PID ist 13203:

kill -TERM 13203
ps -p 13203 -o pid,ppid,user,stat,etime,cmd

Nur wenn der Prozess weiterläuft und ein Abbruch gerechtfertigt ist:

kill -KILL 13203
ps -p 13203 -o pid,ppid,user,stat,etime,cmd

Berechtigungen und Grenzen

Normale Benutzer dürfen in der Regel nur eigene Prozesse signalisieren. Für Prozesse anderer Benutzer oder privilegierte Systemprozesse benötigen Sie häufig administrative Rechte:

sudo kill -TERM 13203

Prüfen Sie vorab den Besitzer mit ps. Beenden Sie keine kritischen Systemprozesse ohne klare Absicht und ohne die möglichen Auswirkungen zu kennen.

Prozessstatus D

Der Status D bezeichnet einen nicht unterbrechbaren Wartestatus. Ein Prozess wartet häufig auf eine Kernel- oder Ein-/Ausgabeoperation, etwa auf einen Datenträger, ein Netzwerk-Dateisystem oder ein problematisches Gerät. Selbst SIGKILL muss einen solchen Prozess nicht sofort verschwinden lassen.

Prüfen Sie den Status mit:

ps -p 13203 -o pid,ppid,user,stat,etime,cmd

Bei D sollten Sie die zugrunde liegenden Datenträger-, Netzwerk- oder Dateisystemprobleme untersuchen.

Zombie-Prozesse

Ein Zombie-Prozess ist bereits beendet. Sein Elternprozess hat den Beendigungsstatus jedoch noch nicht abgeholt. Ein Zombie arbeitet nicht mehr und kann nicht sinnvoll durch ein weiteres kill entfernt werden.

Untersuchen Sie stattdessen den Elternprozess. Gegebenenfalls muss der verantwortliche Dienst kontrolliert neu gestartet oder der Elternprozess zur Statusabholung gebracht werden.

Einzelne PID oder Prozesse nach Namen steuern

kill arbeitet PID-basiert und richtet sich damit an genau die angegebenen Prozess-IDs. Das ist präzise, setzt aber eine korrekte Identifikation voraus.

Namensbasierte Werkzeuge wie killall können mehrere Prozesse mit demselben Namen treffen. Das ist praktisch, aber riskanter, wenn mehrere unabhängige Instanzen laufen. Verwenden Sie bei Unsicherheit eine einzelne PID und prüfen Sie die vollständige Kommandozeile. Weitere Informationen finden Sie unter Prozesse mit killall beenden.

systemd-Dienste bevorzugt über systemctl steuern

Wird ein Prozess von systemd verwaltet, sollten Sie normalerweise die dienstspezifische Steuerung verwenden. Prüfen Sie zunächst den Status:

systemctl status beispiel.service

Für einen solchen Dienst sind systemctl stop oder systemctl restart meist geeigneter als ein direktes Signal an eine einzelne PID. Die Dienstverwaltung berücksichtigt Abhängigkeiten, Überwachung und gegebenenfalls automatisch neu gestartete Prozesse.

Direktes kill kann bei der Fehleranalyse oder als gezielter Notfallmaßnahme sinnvoll sein. Kontrollieren Sie danach aber den Dienststatus, da systemd den Prozess möglicherweise erneut startet.

Fehlerbehebung

„Kein solcher Prozess“

Der Prozess wurde möglicherweise bereits beendet, die PID stammt aus einer alten Ausgabe oder es wurde die falsche PID verwendet. Rufen Sie die Prozessliste erneut ab und prüfen Sie PID und Kommandozeile unmittelbar vor dem Signal.

„Keine Berechtigung“

Der Prozess gehört wahrscheinlich einem anderen Benutzer oder ist privilegiert. Prüfen Sie den Besitzer mit ps. Falls Sie dazu berechtigt sind, verwenden Sie sudo. Beenden Sie kritische Prozesse nicht ohne Verständnis ihrer Funktion.

Der Prozess läuft nach SIGTERM weiter

Das Programm kann noch Aufräumarbeiten durchführen, SIGTERM anders behandeln, ignorieren oder auf eine Ressource warten. Warten Sie kurz, prüfen Sie Status und Logs und setzen Sie SIGKILL nur nach einer Risikoabwägung ein.

Der Prozess verschwindet nach SIGKILL nicht

Prüfen Sie mit ps, ob der Status D vorliegt. Bei einem nicht unterbrechbaren Wartestatus muss zuerst die zugrunde liegende Ein-/Ausgabe- oder Kernel-Problematik gelöst werden. Stellen Sie außerdem sicher, dass Ihre Anzeige aktuell ist.

Das falsche Programm wurde beendet

Ursachen sind eine nicht ausreichend geprüfte PID, ein ungenauer Prozessname oder eine nachträgliche PID-Wiederverwendung. Verwenden Sie vor jedem Signal ps mit PID, Benutzer und vollständiger Kommandozeile. In Skripten sollten zusätzliche Prüfungen und eindeutige Selektoren eingesetzt werden.

Entscheidungshilfe

SituationEmpfohlene AktionWarumRisiko
Normal reagierender Prozesskill -TERM PIDKontrollierte Beendigung mit AufräumarbeitenGeringer, sofern der Prozess korrekt identifiziert wurde
Nach SIGTERM weiterhin nicht reagierendStatus prüfen, danach bei Bedarf kill -KILL PIDEskalation, wenn eine Beendigung erforderlich istDatenverlust und fehlende Aufräumarbeiten
systemd-verwalteter Dienstsystemctl stop oder systemctl restartDienstverwaltung berücksichtigt den Service-KontextAbhängige Dienste können beeinflusst werden
Prozess im Status DEin-/Ausgabe- oder Kernelproblem untersuchenSIGKILL muss D nicht sofort auflösenBlockierte Ressourcen und mögliche Dateisystemprobleme
Zombie-ProzessElternprozess untersuchenDer Zombie ist bereits beendetElternprozess oder zugehöriger Dienst kann betroffen sein

Prüfungsrelevante Merksätze

  • kill PID sendet standardmäßig SIGTERM, beendet aber nicht zwingend sofort.
  • SIGTERM erlaubt dem Programm normalerweise kontrollierte Aufräumarbeiten.
  • SIGKILL ist nicht abfangbar und kann Datenverlust verursachen; es ist der letzte Ausweg.
  • SIGSTOP hält einen Prozess an, SIGCONT setzt ihn fort.
  • Signalnamen sind gegenüber Signalnummern lesbarer und portabler.
  • Vor jedem Signal müssen PID, Prozessname, Benutzer und Kommandozeile geprüft werden.
  • Ein Prozess im Status D oder ein Zombie verhält sich nicht wie ein normal laufender Prozess.
  • Bei systemd-Diensten ist systemctl meist die passendere Steuerung.

Für die allgemeine Prozesssuche können Sie die Werkzeuge dd als Beispiel für ressourcenintensive Befehle und die Bash-Shell als Ausführungsumgebung vertiefen.