"zabić PID" tak naprawdę nie zabijając procesu, dlaczego?

99

Próbuję poprawić moje umiejętności w zakresie linii poleceń i napotkałem problem, w którym nie mogę zabić procesu. Wpisuję kill 2200 , gdzie 2200 to mój PID, a proces nie zostaje zabity. Po kilku minutach oczekiwanie jest nadal w top i ps aux . Próbowałem nawet pisać z sudo - bez rezultatów.

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

EDYTUJ

Znalazłem dziwną zależność, gdzie fg aktualizuje 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
    
zadawane Patryk 03.09.2011, 09:47
źródło

5 odpowiedzi

147

Procesy mogą ignorować niektóre sygnały. Jeśli wyślesz SIGKILL, nie będzie można go zignorować (i nie złapać go, by zrobić porządki). Spróbuj:

kill -9 {PID}

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

man kill
    
odpowiedział Michał Šrajer 03.09.2011, 10:09
źródło
30

Jeśli kill zostanie wywołany bez żadnego parametru, wysyła sygnał o numerze 15 ( SIGTERM ). Ten sygnał może zostać zignorowany przez proces. Ten sygnał powiadamia proces czyszczenia jego rzeczy, a następnie kończy się poprawnie sam. To dobra droga.

Możesz także "wysłać" numer sygnału 9 ( SIGKILL ), którego nie można zignorować przez proces. Proces go nawet nie rozpozna, ponieważ jądro kończy proces, a nie sam proces. To zła droga.

Jeden mówi, że kill -9 <pid> zawsze działa. To jest niewiara . Są sytuacje, w których nawet kill -9 nie zabija procesu. Na przykład, gdy proces ma stan D (nieprzerwany sen). Proces przychodzi do tego stanu za każdym razem, gdy oczekuje na wejście / wyjście (zwykle niezbyt długie). Jeśli więc proces czeka na I / O (na przykład na dysku twardym z defektem) i nie jest poprawnie zaprogramowany (z przekroczeniem limitu czasu), to po prostu nie może zabić procesu . Nie ważne co robisz. Możesz po prostu spróbować udostępnić plik, aby proces był kontynuowany.

    
odpowiedział chaos 10.06.2014, 08:22
źródło
7

Pomimo tego, że nazwa kill nie zabija procesów, wysyła do niej sygnały. Ze strony podręcznika:

kill - send a signal to a process

Domyślnym sygnałem wysyłanym przez kill [pid] jest SIGTERM , co zwykle, lecz niekoniecznie, wymaga zakończenia procesu. Jest całkiem możliwe, aby napisać program, który odgrywa radosną melodię, gdy wyślesz do niego sygnał SIGTERM , ale nie jest to zalecane.

Innym typowym sygnałem jest SIGHUP , który często jest używany do żądania od programu ponownego odczytania jego plików konfiguracyjnych.

Jeśli naprawdę chcesz zabić program, musisz użyć sygnału SIGKILL , wykonując kill -9 [pid] .

    
odpowiedział danne 06.09.2011, 13:51
źródło
2

Wygląda na to, że możesz zawiesić proces (może przez naciśnięcie Ctrl-Z w terminalu). W tym stanie twój proces nie zareaguje na SIGTERM, ponieważ jest zamrożony. Uruchomienie "fg" powoduje rozmrożenie procesu, dzięki czemu może odbierać sygnał i kończyć się samo. To może wyjaśnić, dlaczego "fg" wydaje się aktualizować listę procesów.

    
odpowiedział user24497 06.09.2011, 17:00
źródło
0

Z poziomu C ++ wykonałem:

kill(4024, SIGKILL);

I na terminalu linuksowym (Ubuntu),

$ ps -ax | grep my_su

Dane wyjściowe:

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

Pozornie, to (4024) wciąż żyje. Jednak, gdy tylko zakończyłem proces nadrzędny, który nazwał powyższą instrukcję "zabić", 4024 nie pojawił się więcej. Teraz sądzę, że "nieistniejący" proces jest niczym więcej niż linią wyświetlaną i postanowił ją zignorować. Mam nadzieję, że moje doświadczenie może pomóc komuś tam. Pozdrawiam!

    
odpowiedział Park JongBum 11.03.2016, 00:51
źródło

Przeczytaj inne pytania na temat tagów