kill ist trotz seines Namens kein Mörder, sondern ein Bote: Das Werkzeug schickt Signale an Prozesse. Die meisten dieser Signale beenden zwar tatsächlich den Empfänger — aber eben nur als eine von vielen möglichen Reaktionen. Wer den Unterschied zwischen kill, killall, pkill und pgrep versteht, beendet Prozesse präzise, lädt Dienste sauber neu und vermeidet die Kollateralschäden eines vorschnellen kill -9.
Was kill macht
kill schickt einem Prozess ein Signal. Signale sind ein klassischer Unix-Mechanismus, mit dem der Kernel oder andere Prozesse einem laufenden Programm asynchron mitteilen, dass etwas geschehen soll — höflich beenden, hart abschiessen, anhalten, fortsetzen oder die Konfiguration neu laden.
Ohne weitere Angabe schickt kill das Signal SIGTERM (Nummer 15). Das bedeutet: „Bitte beende dich ordentlich.” Der Prozess kann dieses Signal abfangen, offene Dateien schliessen, Locks freigeben, Kindprozesse aufräumen und sich dann selbst beenden. Der Name kill ist also irreführend — viele Signale dienen anderen Zwecken als dem Beenden.
Du erkennst gut programmierte Software daran, dass sie auf SIGTERM sauber reagiert. Datenbanken, Webserver und langlaufende Daemons nutzen genau diesen Pfad, um sich graceful herunterzufahren.
Syntax
Der grundsätzliche Aufruf ist denkbar schlicht:
kill [-SIGNAL] PID...Das Signal kann auf drei Arten angegeben werden — alle drei Varianten sind äquivalent:
| Form | Beispiel | Bedeutung |
|---|---|---|
| Nummer | kill -9 1234 | Signal Nummer 9 |
| Kurzname | kill -KILL 1234 | Signal KILL |
| Voller Name | kill -SIGKILL 1234 | Signal SIGKILL |
Mehrere PIDs lassen sich in einem Aufruf angeben: kill 1234 5678 9012. Eine vollständige Übersicht aller Signale mit ihren Nummern und Default-Aktionen findest du im Artikel zu Signalen.
kill -lHäufige Signale
Im Alltag begegnen dir vor allem diese sechs Signale:
| Signal | Nummer | Wirkung |
|---|---|---|
| SIGTERM | 15 | Höflich beenden — Default von kill, abfangbar, erlaubt Cleanup |
| SIGKILL | 9 | Hart beenden — nicht abfangbar, kein Cleanup, sofortiger Abbruch |
| SIGINT | 2 | Interrupt — entspricht Strg+C im Terminal |
| SIGHUP | 1 | Hangup — historisch Terminal getrennt, heute oft „Konfiguration neu laden” |
| SIGSTOP | 19 | Prozess pausieren — nicht abfangbar |
| SIGCONT | 18 | Pausierten Prozess fortsetzen |
SIGTERM und SIGKILL gehen ans Beenden. SIGSTOP und SIGCONT pausieren und reaktivieren — nützlich, wenn ein Prozess gerade zu viel CPU zieht und du ihn temporär einfrieren willst, ohne ihn zu verlieren. SIGHUP wird traditionell von Daemons wie nginx oder sshd genutzt, um die Konfiguration neu einzulesen, ohne den Prozess neu zu starten.
killall — by Name
Wenn du die PID nicht weisst (oder mehrere Instanzen eines Programms laufen), greift killall. Es schickt das Signal an alle Prozesse, deren Name dem Argument entspricht:
killall firefoxAuf Linux stammt killall aus dem procps-Paket und arbeitet by-name. Wichtig zu wissen: Auf BSD-Systemen (FreeBSD, klassisch auch Solaris) heisst dasselbe Kommando killall, beendet aber alle Prozesse des aktuellen Users oder gar des gesamten Systems. Wer Skripte zwischen Linux und BSD portiert, erlebt hier sehr böse Überraschungen.
killall -i fragt vor jedem Treffer nach Bestätigung, killall -u USER schränkt auf Prozesse eines Users ein. Mit -9 sendet killall SIGKILL statt SIGTERM — was du nur als allerletzte Option verwenden solltest.
pkill — Pattern-Match
pkill ist die mächtigere Variante von killall. Statt nur den Prozessnamen zu vergleichen, matcht es per Regex — wahlweise auf den Namen oder auf die volle Befehlszeile:
pkill -f myappDer wichtige Schalter ist -f (full command line): Ohne ihn matcht pkill nur gegen den 15-Zeichen-Prozessnamen aus der comm-Spalte. Mit -f wird die komplette Befehlszeile geprüft — inklusive aller Argumente. Damit kannst du z. B. nur das Java-Programm mit einem bestimmten JAR-Argument treffen, ohne andere Java-Prozesse zu erwischen.
Weitere nützliche Filter:
| Option | Wirkung |
|---|---|
-u USER | Nur Prozesse eines bestimmten Users |
-G GROUP | Nur Prozesse einer bestimmten Gruppe |
-t TTY | Nur Prozesse einer bestimmten Terminal-Sitzung |
-n | Nur den jüngsten passenden Prozess |
-o | Nur den ältesten passenden Prozess |
-l | Trockenlauf — passende Prozesse anzeigen, nicht killen |
pkill deckt 95 % der Anwendungsfälle ab, in denen man früher killall benutzt hätte — und ist gleichzeitig portabler im Verhalten.
pgrep — finden ohne killen
pgrep ist die Schwester von pkill: gleiche Match-Logik, aber statt zu killen werden nur die PIDs ausgegeben. Klassisch für Skripte und für „erst schauen, dann killen”:
pgrep -af myapp-a zeigt zusätzlich zur PID die volle Befehlszeile, -f matcht (wie bei pkill) gegen die volle Cmd-Line. In Skripten ist das idiomatisch:
if pgrep -f myapp > /dev/null; then
echo "myapp laeuft bereits"
fiGenauso elegant lässt sich pgrep mit anderen Werkzeugen kombinieren: kill -HUP $(pgrep nginx) schickt SIGHUP an alle nginx-Prozesse.
Praxis-Patterns
Eine Sammlung der Patterns, die in der Praxis immer wieder auftauchen — jedes mit einer kurzen Erläuterung dazu, wann es passt.
Höflich beenden
kill 1234Ohne Signal-Argument geht SIGTERM raus. Erste Wahl bei jedem normalen Beenden — der Prozess bekommt die Chance, aufzuräumen. Reagiert er nicht innerhalb weniger Sekunden, kannst du nachlegen.
Mit Wartezeit dann hart
kill 1234; sleep 5; kill -9 1234Erst SIGTERM, dann fünf Sekunden warten, dann SIGKILL. Genau das machen systemctl stop und ähnliche Werkzeuge intern — höflich anfragen, hart durchgreifen, wenn es nichts hilft.
Per Name killen
pkill -f myappMit Cmd-Line-Match — präziser als killall, weil der gesamte Aufruf inklusive Argumenten geprüft wird. Vor dem Scharfschalten gerne erst mit pgrep -af myapp testen.
Reload triggern
kill -HUP 1234Das klassische Idiom für Konfigurations-Reload: nginx, sshd, rsyslog und viele andere lesen bei SIGHUP ihre Konfiguration neu, ohne den Prozess oder bestehende Verbindungen zu beenden.
Process-Group killen
kill -- -1234Achtung — das Minus vor der PID ist kein Tippfehler, sondern Pflicht: Es sagt kill, dass die Zahl als Process-Group-ID zu interpretieren ist. So beendest du in einem Rutsch einen Eltern-Prozess mit allen seinen Kindprozessen.
User-spezifisch
pkill -u www-data nginxBeendet nur die nginx-Prozesse, die unter dem User www-data laufen. Nützlich auf Servern mit mehreren parallelen Instanzen oder wenn du sehr gezielt eingreifen willst.
Trockenlauf
pkill -l -f PATTERNListet die passenden Prozesse, ohne sie zu killen. Pflicht-Schritt, bevor du ein neues Pattern scharf schaltest — gerade -f matcht oft mehr als gedacht.
PID 1 und kritische Prozesse
Nicht alles lässt sich beenden. PID 1 — also init bzw. systemd — ist gegen jedes Signal geschützt, das nicht explizit installiert wurde. Auch ein kill -9 1 bewirkt nichts. Würde der Kernel PID 1 beenden, käme es zur Kernel-Panic, da der Wurzelknoten des Prozessbaums fehlt.
Auch viele Kernel-Threads (in ps mit eckigen Klammern, z. B. [kworker/...]) lassen sich nicht killen. Sie laufen nicht im User-Space, sondern direkt im Kernel-Adressraum, und reagieren grundsätzlich nicht auf User-Signale.
Zusätzlich gibt es Prozesse im Zustand D (uninterruptible sleep) — typischerweise blockiert in I/O auf einem hängenden Gerät oder NFS-Mount. Auch hier ist SIGKILL wirkungslos, bis der Kernel-Aufruf zurückkehrt. Manchmal hilft nur Reboot.
Stolperfallen
kill -9 zerstoert jede Chance auf Cleanup
SIGKILL (9) ist nicht abfangbar — der Prozess wird vom Kernel sofort beendet, ohne dass sein Code noch eine Zeile ausführen darf. Offene Dateien werden nicht sauber geschlossen, Locks bleiben liegen, Kindprozesse werden zu Orphans, halb geschriebene Datenbank-Transaktionen werden nicht zurückgerollt. Verwende immer zuerst SIGTERM und gib dem Prozess ein paar Sekunden. SIGKILL ist die Notbremse, nicht die Standard-Methode.
pkill ohne -f matcht nur 15 Zeichen
Ohne -f vergleicht pkill (und pgrep, und killall) nur den Prozessnamen aus der comm-Spalte — und der ist auf 15 Zeichen begrenzt. Lange Programmnamen werden abgeschnitten, und Pattern, die du im ps-Output siehst, treffen plötzlich nichts. Mit -f wird stattdessen die volle Befehlszeile geprüft — was du in 90 Prozent der Fälle eigentlich willst.
killall -9 als Default ist Brute-Force
Manche Anleitungen schlagen killall -9 firefox oder ähnliches als Standard-Reflex vor. Das ist Holzhammer-Mentalität: Sämtliche Treffer werden ohne Cleanup gekillt. Bei einem Browser kostet dich das die offenen Tabs, bei einem Editor den ungespeicherten Buffer, bei einer Datenbank die Konsistenz. killall PROGRAMM ohne -9 funktioniert in den meisten Fällen genauso schnell — nur eben sauber.
BSD- vs. Linux-killall — die boesartige Falle
Auf Linux (procps) tötet killall firefox die Prozesse namens „firefox”. Auf BSD-Systemen tötet killall ohne weitere Argumente alle Prozesse, die der ausführende User beenden darf — inklusive der eigenen Login-Shell. Wer Skripte zwischen Linux und BSD austauscht, sollte killall strikt meiden und stattdessen pkill verwenden, das auf beiden Systemen identisch funktioniert.
Exit-Code 1 als Feature: kill -0 prüft ohne zu schicken
kill -0 PID schickt kein Signal, prüft aber, ob der Prozess existiert und du ihn signalisieren dürftest. Existiert er nicht, gibt kill den Exit-Code 1 und die Meldung „No such process” zurück. In Skripten lässt sich das elegant nutzen: kill -0 1234 && echo laeuft. Genau diesen Mechanismus verwenden viele Init-Skripte, um den Status eines Daemons zu prüfen.
PIDs werden recycelt — Race Conditions in Skripten
Linux vergibt PIDs aufsteigend und beginnt nach dem Maximum (meist 32768 oder 4194304) wieder bei kleinen Nummern. Eine gespeicherte PID kann also nach kurzer Zeit zu einem völlig anderen Prozess gehören. Skripte, die PIDs in Dateien ablegen und später ohne Plausibilitätsprüfung killen, beenden im Worst Case einen unbeteiligten Prozess. Verwende für solche Zwecke pid-Files mit cmdline-Vergleich, lockfiles oder gleich systemd.
SIGKILL und SIGSTOP sind nicht abfangbar
Diese beiden Signale kann ein Prozess weder ignorieren noch mit eigenem Handler abfangen — der Kernel führt sie unconditional aus. Das ist die Letzte-Instanz-Eigenschaft des Systems. Konsequenz: Bei SIGKILL gibt es keinerlei Cleanup-Möglichkeit. Bei SIGSTOP friert der Prozess sofort ein, auch mitten in einer Operation — was zu Locks führen kann, die andere Prozesse blockieren, bis du SIGCONT schickst.
Signale werden asynchron zugestellt
Zwischen kill und der tatsächlichen Reaktion des Empfängers liegt ein kurzer, nicht deterministischer Zeitraum. Der Kernel reicht das Signal zu, der Empfänger reagiert in seinem eigenen Tempo — nach dem Ende des aktuellen Kernel-Aufrufs, dem nächsten Scheduling oder gar erst nach Verlassen einer Signal-Mask. Skripte, die ein Signal schicken und sofort danach Wirkung erwarten, sind oft zu ungeduldig. Plane Wartezeiten ein und prüfe mit kill -0 oder pgrep, ob der Prozess wirklich weg ist.
Weiterführende Ressourcen
Externe Quellen
- kill(1) – Linux Manpage (man7.org) — Offizielle Manpage des
kill-Kommandos - killall(1) – procps Manpage — Linux-Variante von
killall - pkill(1) / pgrep(1) – procps Manpage — Pattern-basierte Geschwister
- signal(7) – Signal-Übersicht — Vollständige Signal-Referenz mit Default-Aktionen
- procps-ng Projekt — Quellen und Issue-Tracker des procps-Pakets
- Arch Wiki: Process management — Praktischer Überblick mit Beispielen
Verwandte Artikel
- Signale — Vollständige Liste aller Unix-Signale und ihrer Default-Aktionen
- Prozess-Modell — PID, PPID, fork/exec und der Lebenszyklus eines Prozesses
- ps – Prozesse anzeigen — Welche Prozesse laufen und welche PIDs sie haben
- btop – Interaktives Monitoring — Prozesse live beobachten und aus dem TUI heraus signalisieren
- Linux Berechtigungen — Wer darf welchem Prozess Signale schicken