«убить PID» не убивает процесс, почему?

88

Я пытаюсь улучшить свои навыки командной строки, и я столкнулся с проблемой, когда я не могу убить процесс. Я набираю kill 2200 , где 2200 - мой PID, и процесс не убит. После нескольких минут ожидания все еще находится в top и ps aux . Я даже попытался ввести его с помощью sudo - никаких результатов.

Любые идеи, почему это будет так?

ИЗМЕНИТЬ

Я нашел странную зависимость, где fg обновляет список процессов:

[email protected]:/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
[email protected]:/etc/grub.d$ fg
top

[email protected]:/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
[email protected]:/etc/grub.d$ fg
top

[email protected]:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps
    
задан Patryk 03.09.2011 в 07:47
источник

5 ответов

135

Процессы могут игнорировать некоторые сигналы. Если вы отправляете SIGKILL, он не сможет игнорировать его (и не поймать его на очистку). Попробуйте:

kill -9 {PID}

Подробнее читайте на странице руководства:

man kill
    
ответ дан Michał Šrajer 03.09.2011 в 08:09
источник
28

Если kill вызывается без какого-либо параметра, он отправляет номер сигнала 15 ( SIGTERM ). Процесс может быть проигнорирован этим сигналом. Этот сигнал уведомляет процесс, чтобы очистить его вещи, а затем закончить сам. Это хороший способ.

Вы также можете «отправить» номер сигнала 9 ( SIGKILL ), который не может быть проигнорирован процессом. Этот процесс даже не распознает его, потому что ядро ​​завершает процесс, а не сам процесс. Это злой путь.

Говорят, что kill -9 <pid> всегда работает. Это неверность . Бывают ситуации, когда даже kill -9 не убивает процесс. Например, когда процесс имеет состояние D (непрерывный сон). Процесс приходит в это состояние каждый раз, когда он ждет ввода-вывода (обычно не очень долго). Итак, если процесс ожидает ввода-вывода (например, на жестком диске дефекта), и он не запрограммирован должным образом (с таймаутом), вы просто не можете убить процесс . Не важно, что вы делаете. Вы просто можете попытаться сделать файл доступным, чтобы процесс продолжался.

    
ответ дан chaos 10.06.2014 в 06:22
6

Несмотря на то, что это имя убивает, на самом деле не убивает процессы, он посылает на него сигналы. На странице man:

kill - send a signal to a process

Сигнал по умолчанию, посланный kill [pid] , SIGTERM , который обычно, но не обязательно, требует завершения процесса. Вполне возможно написать программу, которая играет счастливую мелодию, когда вы посылаете ей сигнал SIGTERM , но не рекомендуется.

Другим распространенным сигналом является SIGHUP , который часто используется, чтобы попросить программу перечитать ее файлы конфигурации.

Если вы действительно хотите убить программу, вам нужно использовать сигнал SIGKILL , выполнив kill -9 [pid] .

    
ответ дан danne 06.09.2011 в 11:51
2

Похоже, вы можете приостановить процесс (возможно, нажав Ctrl-Z в терминале). В этом состоянии ваш процесс не будет реагировать на SIGTERM, поскольку он заморожен. Запуск «fg» оттаивает процесс, поэтому он может подхватывать сигнал и автоматически останавливаться. Это может объяснить, почему «fg», похоже, обновляет список процессов.

    
ответ дан user24497 06.09.2011 в 15:00
0

Из C ++ я выполнил:

kill(4024, SIGKILL);

И на терминале linux (Ubuntu),

$ ps -ax | grep my_su

Выход был:

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

По-видимому, он (4024) все еще выживает. Однако, как только я прекратил родительский процесс, который вызвал вышеупомянутый оператор «kill», 4024 больше не появлялся. Теперь я сужу «несуществующий» процесс - это не что иное, как отображаемая строка, и решил проигнорировать ее. Надеюсь, мой опыт может помочь кому-то там. Ура!

    
ответ дан Park JongBum 10.03.2016 в 23:51