Co jeśli „kill -9” nie działa?

Mam proces, którego nie mogę zabić kill -9 <pid>. Jaki jest problem w takim przypadku, zwłaszcza że jestem właścicielem tego procesu. Myślałem, że nic nie może uniknąć tej killopcji.

kill -9( SIGKILL ) zawsze działa, pod warunkiem, że masz pozwolenie na zabicie procesu. Zasadniczo albo proces musi zostać rozpoczęty przez ciebie, a nie być ustawiony jako setuid lub setgid, albo musisz być rootem. Jest jeden wyjątek: nawet root nie może wysłać fatalnego sygnału do PID 1 ( initproces).

Nie kill -9gwarantuje się jednak natychmiastowej pracy . Wszystkie sygnały, w tym SIGKILL, są dostarczane asynchronicznie: jądro może zająć trochę czasu, aby je dostarczyć. Zwykle dostarczenie sygnału zajmuje najwyżej kilka mikrosekund, tyle ile potrzeba, aby cel otrzymał przedział czasu. Jeśli jednak cel zablokował sygnał , sygnał będzie w kolejce, dopóki cel go nie odblokuje.

Zwykle procesy nie mogą blokować SIGKILL. Ale kod jądra może i procesy wykonują kod jądra, gdy wywołują wywołania systemowe . Kod jądra blokuje wszystkie sygnały, gdy przerwanie wywołania systemowego spowodowałoby źle sformułowaną strukturę danych gdzieś w jądrze, lub bardziej ogólnie, naruszenie niektórych niezmienników jądra. Więc jeśli (z powodu błędu lub błędnego zaprojektowania) wywołanie systemowe blokuje się w nieskończoność, może nie być skutecznie zabić tego procesu. (Ale proces zostanie zabity, jeśli kiedykolwiek zakończy wywołanie systemowe).

Proces zablokowany w wywołaniu systemowym znajduje się w nieprzerwanym trybie uśpienia . Polecenie pslub toppokaże (w większości jednorożców) stan D(pierwotnie jak sądzę dla „ d isk”).

Klasycznym przypadkiem długiego nieprzerwanego uśpienia są procesy uzyskiwania dostępu do plików przez NFS, gdy serwer nie odpowiada; nowoczesne implementacje zwykle nie narzucają nieprzerwanego uśpienia (np. w Linuksie intropcja montowania pozwala na sygnał przerywający dostęp do plików NFS).

Można czasem zobaczyć wpisy oznaczone Z(lub Hpod Linuksem, nie wiem jaka jest różnica) w pslub topwyjście. Nie są to technicznie procesy, są to procesy zombie, które są niczym więcej niż wpisem w tabeli procesów, przechowywanym tak, aby proces nadrzędny mógł zostać powiadomiony o śmierci swojego dziecka. Odejdą, gdy proces nadrzędny zwróci uwagę (lub umrze).

Czasami istnieje proces i nie można go zabić z powodu:

• będąc zombie. Tj. Proces, który rodzic nie odczytał statusu wyjścia. Taki proces nie zużywa żadnych zasobów oprócz wpisu PID. W toptym sygnalizowane jest Z
• błędny nieprzerwany sen. To nie powinno się zdarzyć, ale z kombinacją błędnego kodu jądra i / lub błędnego sprzętu, co kiedyś robi. Jedyną metodą jest ponowne uruchomienie lub poczekanie. W toptym sygnalizuje D.

Wygląda na to, że masz proces zombie . Jest to nieszkodliwe: jedynym zasobem zużywanym przez proces zombie jest wpis w tabeli procesów. Odejdzie, gdy proces rodzicielski umrze lub zareaguje na śmierć dziecka.

Możesz sprawdzić, czy proces jest zombie za pomocą toplub następującego polecenia:

ps aux | awk '$8=="Z" {print $2}'

Sprawdź swoje /var/log/kern.logi /var/log/dmesg(lub ich odpowiedniki) pod kątem jakichkolwiek wskazówek. Z mojego doświadczenia wynika, że ​​zdarzyło mi się to tylko wtedy, gdy połączenie sieciowe uchwytu NFS nagle spadło lub nastąpił awaria sterownika urządzenia. Może się zdarzyć, jeśli dysk twardy również się zawiesi.

Możesz użyć, lsofaby zobaczyć, jakie pliki urządzenia otworzył proces.

Jeśli odpowiedzi @ Macieja i @ Gillesa nie rozwiążą twojego problemu, a ty nie rozpoznajesz procesu (i pytanie, co to jest z twoją dystrybucją, nie pojawia się odpowiedzi). Sprawdź Rootkita i wszelkie inne znaki, które były Twoją własnością . Rootkit jest więcej niż w stanie zapobiec zabiciu tego procesu. W rzeczywistości wielu jest w stanie uniemożliwić ci ich zobaczenie. Ale jeśli zapomną zmodyfikować 1 mały program, mogą zostać zauważeni (np. Zmodyfikowali top, ale nie htop). Najprawdopodobniej tak nie jest, ale lepiej zabezpieczyć niż przepraszać.

Kill faktycznie oznacza wysłanie sygnału. istnieje wiele sygnałów, które możesz wysłać. kill -9 to specjalny sygnał.

Podczas wysyłania sygnału aplikacja się tym zajmuje. jeśli nie, jądro sobie z tym poradzi. dzięki czemu można złapać sygnał w aplikacji.

Ale powiedziałem, że kill -9 był wyjątkowy. Jest to wyjątkowe, ponieważ aplikacja go nie otrzymuje. idzie prosto do jądra, które następnie naprawdę zabija aplikację przy pierwszej możliwej okazji. innymi słowy zabija go martwego

kill -15 wysyła sygnał SIGTERM, który oznacza SIGNAL TERMINATE, innymi słowy, informuje aplikację o zakończeniu. Jest to przyjazny sposób na poinformowanie aplikacji, że czas zamknąć. ale jeśli aplikacja nie odpowiada, zabij -9.

jeśli kill -9 nie działa, prawdopodobnie oznacza to, że twoje jądro nie działa. ponowne uruchomienie jest w porządku. Nie pamiętam, żeby to się kiedykolwiek wydarzyło.

Najpierw sprawdź, czy jest to proces Zombie (co jest bardzo możliwe):

ps -Al

Zobaczysz coś takiego:

0 Z  1000 24589     1  0  80   0 -     0 exit   ?        00:00:00 soffice.bin <defunct>

(Zwróć uwagę na „Z” po lewej)

Jeśli piąta kolumna nie jest 1, oznacza to, że ma proces nadrzędny. Spróbuj zabić ten identyfikator procesu nadrzędnego .

Jeśli jego PPID = 1, NIE ZABIJ GO !! , zastanów się, które inne urządzenia lub procesy mogą być z tym powiązane.

Na przykład, jeśli korzystasz z zamontowanego urządzenia lub samby, spróbuj odmontować. To może uwolnić proces Zombie.

UWAGA : Jeśli ps -Al(lub top) pokazuje „D” zamiast „Z”, może to być związane ze zdalnym montowaniem (jak NFS). Z mojego doświadczenia wynika, że ​​ponowne uruchomienie jest jedyną drogą, aby się tam dostać, ale możesz sprawdzić inne odpowiedzi, które dotyczą tej sprawy bardziej szczegółowo.

Proces inicjacji jest odporny na SIGKILL.

Dotyczy to również wątków jądra, tj. „Procesów” o PPID równym 0.

Jak wspomnieli inni, proces w nieprzerwanym śnie nie może zostać zabity natychmiast (lub w niektórych przypadkach w ogóle). Warto zauważyć, że inny stan procesu, TASK_KILLABLE, został dodany w celu rozwiązania tego problemu w niektórych scenariuszach, szczególnie w częstym przypadku, gdy proces oczekuje na NFS. Zobacz http://lwn.net/Articles/288056/

Niestety nie wierzę, że jest to używane gdziekolwiek w jądrze oprócz NFS.

Stworzyłem mały skrypt, który bardzo mi pomógł!

Możesz go użyć do zabicia dowolnego procesu o podanej nazwie na ścieżce (zwróć na to uwagę !!) Lub możesz zabić dowolny proces danego użytkownika za pomocą parametru „-u nazwa użytkownika”.

#!/bin/bash

if [ "$1" == "-u" ] ; then\n
        PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
        processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
        echo "############# Killing all processes of user: $2 ############################"
else
        echo "############# Killing processes by name: $1 ############################"
        processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi


for process in $processes ; do
        # "command" stores the entire commandline of the process that will be killed
        #it may be useful to show it but in some cases it is counter-productive
        #command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
        echo "Killing process: $process"
        echo ""
        kill -9 $process
done

Są przypadki, w których nawet jeśli wyślesz zabicie -9 do procesu, ten pid zatrzyma się, ale proces uruchomi się ponownie automatycznie (na przykład, jeśli spróbujesz gnome-panel, uruchomi się ponownie): czy może tak być w tym przypadku?

od tutaj pierwotnie :

sprawdź, czy strace coś pokazuje

strace -p <PID>

spróbuj dołączyć do procesu za pomocą gdb

gdb <path to binary> <PID>

jeśli proces wchodził w interakcję z urządzeniem, które można odmontować, usuń moduł jądra lub fizycznie odłącz / odłącz ... wtedy spróbuj tego.

Miałem taki problem. Był to program, który uruchomiłem stracei przerwałem Ctrl+ C. Skończyło się na T(śledzonym lub zatrzymanym) stanie. Nie wiem, jak to się dokładnie stało, ale z tym nie można było się zmobilizować SIGKILL.

Krótko mówiąc, udało mi się go zabić gdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit

W oparciu o wskazówkę z odpowiedzi Gillesa miałem proces oznaczony „Z” u góry ( <defunct>w ps), który zużywał zasoby systemowe, miał nawet otwarty port, który SŁUCHAŁO i można było się z nim połączyć. To było po wykonaniu kill -9na nim. Jego rodzicem było „1” (tj. init), Więc teoretycznie powinno się je po prostu powtórzyć i zniknąć. Ale tak nie było, trzymał się, choć nie biegł i „nie umierał”

Więc w moim przypadku był to zombie, ale wciąż zużywał zasoby ... FWIW.

I nie było usuwalne przez dowolną liczbę kill -9„s

I jego rodzic był, initale nie był zbierany (czyszczony). Czyli initmiała dziecko zombie.

Ponowne uruchomienie nie było konieczne, aby rozwiązać problem. Chociaż ponowne uruchomienie „zadziałałoby” w przypadku problemu / przyspieszyło jego zamknięcie. Po prostu nie był pełen wdzięku, co wciąż było możliwe.

Był to port LISTEN należący do procesu zombie (a także kilka innych portów, takich jak status CLOSE_WAIT połączonych localhost z localhost). I nawet zaakceptował połączenia. Nawet jako zombie. Wydaje mi się, że nie udało się jeszcze wyczyścić portów, więc połączenia przychodzące były nadal dodawane do zaległości portów nasłuchujących TCP, choć nie miały szans na akceptację.

Wiele z powyższych jest określanych jako „niemożliwe” w różnych miejscach w interwebach.

Okazuje się, że miałem w sobie wewnętrzny wątek, który wykonywał „wywołanie systemowe” (w tym przypadku ioctl), którego powrót zajął kilka godzin (było to oczekiwane zachowanie). Wygląda na to, że system nie może zabić całego procesu, dopóki nie wróci z ioctlwywołania, ale przypuszcza, że ​​wkracza na ziemię jądra. Po kilku godzinach wrócił, wszystko się wyjaśniło, a gniazda zostały automatycznie zamknięte itp., Zgodnie z oczekiwaniami. To trochę marnuje czas w celi śmierci! Jądro cierpliwie czekało na jego zabicie.

Aby odpowiedzieć na OP, czasami trzeba poczekać. Długi czas. W końcu zabije.

Sprawdź także dmesg, aby sprawdzić, czy wystąpiła panika jądra (tj. Błąd jądra).