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:

pgrep mc (oder auch ps aux | grep mc)

<pid-vom-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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 548496

Url: https://administrator.de/forum/linux-kill-killt-nicht-548496.html

Ausgedruckt am: 23.12.2024 um 04:12 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

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.

Zitat von @SeaStorm:

ist -9 bei dir wirklich -TERM ?

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

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

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?

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/mc

Das 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

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
19:15:53.367458 read(4, "Process 1907 attached\r\n", 128) = 23 <0.000040>  
19:15:53.367574 write(1, "Process 1907 attached\r\n", 23) = 23 <0.000051>  
19:15:53.367751 select(7, [0 4 6], NULL, NULL, NULL) = 1 (in ) <38.169001>
19:16:31.536851 read(0, "\3", 128) = 1 <0.000016>  
19:16:31.536915 write(4, "\3", 1 <detached ...>  