6
Linux Kill killt nicht
Hi,
ich lese überall, dass der Befehl "kill -9 <pid>" sofort, gnadenlos und *immer* den Prozess mit der angegebenen PID beendet.
Leider nicht auf meinem Ubuntu 14.04 LTS, aktueller Patch Stand (auf einer virtueller Maschine im MS Azure, falls das wichtig ist).
Ich verbinde mich via SSH auf den Server und führe als erstes Kommando tmux aus.
Im tmux starte ich dann mc (Midnight Commander)
Der bleibt aber ab und an mal hängen (und lässt sich dann nicht ein weiteres Mal starten, nur das Fenster friert dann ein, also mache ich das nicht mehr)
Nun kann ich mit CTRL+B+SHIFT+& die tmux Session beenden, was auch klappt, aber da wird der gestartete mc nicht mitgenommen. Auch ein exit und re-connect via SSH hilft da nicht.
Diesen mc will ich nun killen, damit ich ihn wieder verwenden kann:
Nun killen:
mc läuft immer noch. pgrep, ps und pstree sagen nun, dass der mc immer noch läuft
Weiss jemand, was hier schief geht könnte bzw. in welchen Fällen "kill -9" eben doch nicht *immer* killt?
Oder probiert kill über einen längeren Zeitraum zu killen? Davon habe ich aber bisher noch nichts gehört.
Hat jemand eine Erklärung? Ich muss sonst immer den Server neu starten. Das geht zwar sehr schnell, sollte aber eher in der Windows Welt anzutreffen sein
ich lese überall, dass der Befehl "kill -9 <pid>" sofort, gnadenlos und *immer* den Prozess mit der angegebenen PID beendet.
Leider nicht auf meinem Ubuntu 14.04 LTS, aktueller Patch Stand (auf einer virtueller Maschine im MS Azure, falls das wichtig ist).
Ich verbinde mich via SSH auf den Server und führe als erstes Kommando tmux aus.
Im tmux starte ich dann mc (Midnight Commander)
Der bleibt aber ab und an mal hängen (und lässt sich dann nicht ein weiteres Mal starten, nur das Fenster friert dann ein, also mache ich das nicht mehr)
Nun kann ich mit CTRL+B+SHIFT+& die tmux Session beenden, was auch klappt, aber da wird der gestartete mc nicht mitgenommen. Auch ein exit und re-connect via SSH hilft da nicht.
Diesen mc will ich nun killen, damit ich ihn wieder verwenden kann:
- pgrep mc (oder auch ps aux | grep mc)
Nun killen:
- kill -9 <pid-vom-mc>
mc läuft immer noch. pgrep, ps und pstree sagen nun, dass der mc immer noch läuft
Weiss jemand, was hier schief geht könnte bzw. in welchen Fällen "kill -9" eben doch nicht *immer* killt?
Oder probiert kill über einen längeren Zeitraum zu killen? Davon habe ich aber bisher noch nichts gehört.
Hat jemand eine Erklärung? Ich muss sonst immer den Server neu starten. Das geht zwar sehr schnell, sollte aber eher in der Windows Welt anzutreffen sein
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 548496
Url: https://administrator.de/contentid/548496
Ausgedruckt am: 05.11.2024 um 19:11 Uhr
6 Kommentare
Neuester Kommentar
ist -9 bei dir wirklich -TERM ?
Was passiert wenn du den prozess straced ?
Mach mal
strace -Tttf -o strace.out -p PID &
kill -TERM PID
Was passiert wenn du den prozess straced ?
Mach mal
strace -Tttf -o strace.out -p PID &
kill -TERM PID
1
Das kann verschiedene Ursachen haben:
1) Du versuchst einen Prozess zu killen, der nicht dir gehört. Führst du den "kill" auch mit Root-Rechten aus?
2) "kill" ist bei manchen Distributionen in der Bash integriert und hat dann teilweise komische Einschränkungen. Versuche es mal explizit mit "/bin/kill" - das verhindert, dass das Bash-Integrierte "kill" ausgeführt wird sondern das echte.
3) Wenn der Prozess auf I/O wartet (das kann eine Datei sein, aber auch Geräte oder STDIO) kann man ihn nicht herkömmlich unterbrechen, weil der Kernel ihn aufgrund der wartenden File-Handles künstlich am Leben erhält. Es muss dann erst dieser I/O-Vorgang abgeschlossen werden, bis der Prozess wirklich getötet wird.
Das lässt sich manchmal (nicht immer) umgehen, indem man den Prozess mit SIGSEGV wegtötet. Damit wird dem Kernel signalisiert, dass der Prozess einen Segfault verursacht hätte und sowas kann meistens auch wartende I/O-Anforderungen ebenfalls töten.
Probiere mal "/bin/kill -s SIGSEGV $(pidof mc)" - auch hier wieder mit explizitem Aufruf der Binary.
1) Du versuchst einen Prozess zu killen, der nicht dir gehört. Führst du den "kill" auch mit Root-Rechten aus?
2) "kill" ist bei manchen Distributionen in der Bash integriert und hat dann teilweise komische Einschränkungen. Versuche es mal explizit mit "/bin/kill" - das verhindert, dass das Bash-Integrierte "kill" ausgeführt wird sondern das echte.
3) Wenn der Prozess auf I/O wartet (das kann eine Datei sein, aber auch Geräte oder STDIO) kann man ihn nicht herkömmlich unterbrechen, weil der Kernel ihn aufgrund der wartenden File-Handles künstlich am Leben erhält. Es muss dann erst dieser I/O-Vorgang abgeschlossen werden, bis der Prozess wirklich getötet wird.
Das lässt sich manchmal (nicht immer) umgehen, indem man den Prozess mit SIGSEGV wegtötet. Damit wird dem Kernel signalisiert, dass der Prozess einen Segfault verursacht hätte und sowas kann meistens auch wartende I/O-Anforderungen ebenfalls töten.
Probiere mal "/bin/kill -s SIGSEGV $(pidof mc)" - auch hier wieder mit explizitem Aufruf der Binary.
1
Will ich -TERM? Ich will doch -KILL. Laut kill -l ist das -9 (-SIGKILL)
Was passiert wenn du den prozess straced ?
strace -Tttf -o strace.out -p PID & kill -TERM PID
strace -Tttf -o strace.out -p PID & kill -TERM PID
Erklär bitte mal kurz, warum das was bringen könnte bzw. was das anders macht als kill -9 <pid>
meine ich doch
macht nix anderes ... naja ausser halt term statt sigkill, aber es geht um die trace-datei. In der kannst du sehen was im Prozess passiert wenn du ihn killen willst und damit wahrscheinlich auch den Grund, warum du ihn nicht killen kannst
macht nix anderes ... naja ausser halt term statt sigkill, aber es geht um die trace-datei. In der kannst du sehen was im Prozess passiert wenn du ihn killen willst und damit wahrscheinlich auch den Grund, warum du ihn nicht killen kannst
Zitat von @LordGurke:
1) Du versuchst einen Prozess zu killen, der nicht dir gehört. Führst du den "kill" auch mit Root-Rechten aus?
1) Du versuchst einen Prozess zu killen, der nicht dir gehört. Führst du den "kill" auch mit Root-Rechten aus?
Nein, ich starte tmux und mc und kill. Ich könnte das sudo-en, sehe aber die Notwendigkeit nicht. Es kommt ja auch keine Zugriffsfehler Meldung vom kill.
2) "kill" ist bei manchen Distributionen in der Bash integriert ...
- which kill
- /bin/kill
3) Wenn der Prozess auf I/O wartet ...
steam@Mumpelpunkt:/tmp$ sudo lsof | grep bin/mc
lsof: WARNING: can't stat() fuse.sshfs file system /home/steam/mumpelpunkt.de
Output information may be incomplete.
mc 1907 steam txt REG 8,1 979736 2859 /usr/bin/mcDas könnte tatsächlich eine heisse Spur sein, da ich nach dem Start des mc noch ein entferntes Dateisystem mittels sshfs (fusermount) einbinde.
Probiere mal "/bin/kill -s SIGSEGV $(pidof mc)" - auch hier wieder mit explizitem Aufruf der Binary.
Hat leider nichts gebracht:
steam@Mumpelpunkt:~$ pgrep mc
1907
steam@Mumpelpunkt:~$ /bin/kill -s SIGSEGV 1907
steam@Mumpelpunkt:~$ pgrep mc
1907
steam@Mumpelpunkt:~$ /bin/kill -s SIGSEGV $(pgrep mc)
# 3 Minuten später:
steam@Mumpelpunkt:~$ pgrep mc
1907
steam@Mumpelpunkt:~$Ups, während ich das schreibe, ca. 10 Minuten später, hat sich die Console von selbst geschlossen und in einer neuen SSH Sitzung war tatsächlich kein mc mehr da. Das müßte aber schneller gehen.
Ich werde das Dateisystem zukünftig VOR dem Start des mc einbinden, mal schauen...
Danke erstmal für den Tipp
PS: Ich muss nun erst mal nachlesen, was die Spalten "FD" und "TYPE" bei lsof bedeutet. mc hat da "txt" und "REG" stehen. Seit wann hat Linux eine Registry
Zitat von @SeaStorm:
es geht um die trace-datei. In der kannst du sehen was im Prozess passiert wenn du ihn killen willst und damit wahrscheinlich auch den Grund, warum du ihn nicht killen kannst
es geht um die trace-datei. In der kannst du sehen was im Prozess passiert wenn du ihn killen willst und damit wahrscheinlich auch den Grund, warum du ihn nicht killen kannst
Ach so
Da der mc sich nicht killen läßt, mußte ich strace mittels STRG+C beenden, das ist das Ergebnis:
steam@Mumpelpunkt:~$ cat strace.out
1907 19:15:53.367458 read(4, "Process 1907 attached\r\n", 128) = 23 <0.000040>
1907 19:15:53.367574 write(1, "Process 1907 attached\r\n", 23) = 23 <0.000051>
1907 19:15:53.367751 select(7, [0 4 6], NULL, NULL, NULL) = 1 (in ) <38.169001>
1907 19:16:31.536851 read(0, "\3", 128) = 1 <0.000016>
1907 19:16:31.536915 write(4, "\3", 1 <detached ...> Kann man da was erkennen?
