„Kill <PID>” tak naprawdę nie zabija procesu, dlaczego?

Próbuję poprawić swoje umiejętności wiersza poleceń i napotkałem problem polegający na tym, że nie mogę zabić procesu. Wpisuję kill 2200gdzie 2200 to mój PID i proces ten nie zostanie zabity. Po kilku minutach nadal czeka topi ps aux. Próbowałem nawet pisać z sudo - bez rezultatów.

Jakieś pomysły, dlaczego tak by było?

EDYTOWAĆ

Znalazłem dziwną zależność, w której fgaktualizuje listę procesów:

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

Procesy mogą ignorować niektóre sygnały. Jeśli wyślesz SIGKILL, nie będzie w stanie go zignorować (i nie złapać go, aby wykonać czyszczenie). Próbować:

kill -9 {PID}

Dowiedz się więcej, czytając stronę podręcznika:

man kill

Jeśli killzostanie wywołany bez żadnego parametru, wyśle ​​sygnał o numerze 15 ( SIGTERM). Ten sygnał może zostać zignorowany przez proces. Ten sygnał powiadamia o procesie czyszczenia jego rzeczy, a następnie sam się poprawnie kończy. To dobry sposób.

Możesz także „wysłać” sygnał o numerze 9 ( SIGKILL), którego proces nie może zignorować. Proces nawet go nie rozpozna, ponieważ jądro kończy proces, a nie sam proces. To zły sposób.

Mówi się, że kill -9 <pid>zawsze działa. To nieprawda . Są sytuacje, w których nawet kill -9nie zabija procesu. Na przykład, gdy proces ma stan D(nieprzerwany sen). Proces wchodzi w ten stan za każdym razem, gdy czeka na We / Wy (zwykle niezbyt długi). Jeśli więc proces czeka na operacje we / wy (na przykład na dysku twardym z defektami) i nie jest odpowiednio zaprogramowany (z przekroczeniem limitu czasu), po prostu nie można go zabić . Nie ważne co robisz. Możesz po prostu spróbować udostępnić plik, aby proces był kontynuowany.

Mimo że nazwa zabija w rzeczywistości nie zabija procesów, wysyła do niego sygnały. Ze strony podręcznika:

kill - send a signal to a process

Domyślnym sygnałem wysyłanym przez kill [pid]jest SIGTERM, który zwykle, ale niekoniecznie, prosi proces o zakończenie. Jest całkiem możliwe napisanie programu, który gra wesołą melodię po wysłaniu do niego sygnału SIGTERM , ale nie jest to zalecane.

Innym częstym sygnałem jest SIGHUP, który jest często używany do proszenia programu o ponowne odczytanie plików konfiguracyjnych.

Jeśli naprawdę chcesz zabić program, musisz użyć sygnału SIGKILLkill -9 [pid] .

Wygląda na to, że możesz zawiesić proces (być może przez naciśnięcie Ctrl-Z w terminalu). W tym stanie proces nie reaguje na SIGTERM, ponieważ jest zamrożony. Uruchomienie „fg” rozmraża proces, dzięki czemu może on odebrać sygnał i sam się zakończyć. To może wyjaśniać, dlaczego „fg” wydaje się aktualizować listę procesów.

Z poziomu C ++ wykonałem:

kill(4024, SIGKILL);

A na terminalu Linux (Ubuntu)

$ ps -ax | grep my_su

Wynik był:

4024 pts/1    Z+     0:00 [my_subscriber] <defunct>

Najwyraźniej to (4024) wciąż przetrwało. Jednakże, jak tylko zakończyłem proces nadrzędny, który wywołał powyższą instrukcję „kill”, 4024 już się nie pojawił. Teraz oceniam, że proces „nieczynny” jest niczym więcej niż wyświetlaną linią i postanowiłem go zignorować. Mam nadzieję, że moje doświadczenie może komuś pomóc. Twoje zdrowie!

Możesz także użyć kill -ldo wyświetlenia obsługiwanych sygnałów przez swoją architekturę i dowiedzieć się więcej o sygnale, którego możesz chcieć użyć do prawidłowego wysłania sygnału.

Uwaga: jak wspomnieli inni, użycie kill -9 {PID}nie jest zalecane, chyba że jest to proces zombie. po otrzymaniu procesu SIGKILL natychmiast się wyłączy bez czyszczenia lub innych odpowiednich procedur.

Właśnie tego użyłem do pigułki localhost działającego na porcie 80 (przez kątowe cli) Uzyskaj informacje o uruchomionej aplikacji na porcie 80

sudo lsof -i tcp:80

After That 
sudo kill -9 3348

gdzie 3348jest pid z uruchomionego procesu