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
| Signalname | Typische Nummer | Wirkung | Abfangbar oder ignorierbar? | Typischer Einsatz |
|---|---|---|---|---|
| SIGHUP | 1 | Historisch: Verlust des Kontrollterminals; bei vielen Diensten Aufforderung zum Neuladen der Konfiguration | Programmabhängig | Konfiguration neu einlesen, sofern unterstützt |
| SIGTERM | 15 | Reguläre Beendigungsanfrage | Üblicherweise ja | Erster Versuch beim Beenden |
| SIGKILL | 9 | Sofortige Beendigung durch den Kernel | Nein | Letzter Ausweg |
| SIGSTOP | plattformabhängig | Prozess sofort anhalten | Nein | Vorübergehend anhalten |
| SIGCONT | plattformabhängig | Angehaltenen Prozess fortsetzen | Nicht als Stop-Signal behandelt | Nach 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
- Identifizieren: Suchen Sie den Prozess mit
top,ps,pgrepoderhtop. - Prüfen: Vergleichen Sie PID, Prozessname, vollständige Kommandozeile, Benutzer, CPU-Auslastung und mögliche Abhängigkeiten.
- Besitzverhältnisse bewerten: Klären Sie, ob der Prozess Ihnen gehört und welche Anwendung oder welcher Dienst davon abhängt.
- SIGTERM senden: Verwenden Sie zunächst
kill -TERM PID. - Status kontrollieren: Prüfen Sie mit
ps,top, Logs oder dem Dienststatus, ob der Prozess verschwunden ist oder beendet wird. - Eskalieren: Verwenden Sie nur bei Bedarf und vertretbarem Risiko
kill -KILL PID. - 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
| Situation | Empfohlene Aktion | Warum | Risiko |
|---|---|---|---|
| Normal reagierender Prozess | kill -TERM PID | Kontrollierte Beendigung mit Aufräumarbeiten | Geringer, sofern der Prozess korrekt identifiziert wurde |
| Nach SIGTERM weiterhin nicht reagierend | Status prüfen, danach bei Bedarf kill -KILL PID | Eskalation, wenn eine Beendigung erforderlich ist | Datenverlust und fehlende Aufräumarbeiten |
| systemd-verwalteter Dienst | systemctl stop oder systemctl restart | Dienstverwaltung berücksichtigt den Service-Kontext | Abhängige Dienste können beeinflusst werden |
| Prozess im Status D | Ein-/Ausgabe- oder Kernelproblem untersuchen | SIGKILL muss D nicht sofort auflösen | Blockierte Ressourcen und mögliche Dateisystemprobleme |
| Zombie-Prozess | Elternprozess untersuchen | Der Zombie ist bereits beendet | Elternprozess oder zugehöriger Dienst kann betroffen sein |
Prüfungsrelevante Merksätze
kill PIDsendet standardmäßigSIGTERM, beendet aber nicht zwingend sofort.SIGTERMerlaubt dem Programm normalerweise kontrollierte Aufräumarbeiten.SIGKILList nicht abfangbar und kann Datenverlust verursachen; es ist der letzte Ausweg.SIGSTOPhält einen Prozess an,SIGCONTsetzt 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
Doder ein Zombie verhält sich nicht wie ein normal laufender Prozess. - Bei systemd-Diensten ist
systemctlmeist 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.