& ldquo; kill & lt; PID & gt; & lt; почему бы не убить этот процесс?
Я пытаюсь улучшить свои навыки командной строки, и я столкнулся с проблемой, когда я не могу убить процесс. Я набираю kill 2200, где 2200 - мой PID, и процесс не убит. Через несколько минут все еще ждут top и ps aux. Я даже попробовал набрать его с помощью sudo - никаких результатов.
Любые идеи, почему это будет так?
EDIT
Я нашел странную зависимость, где fg обновляет список процессов:
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
4 ответа
Если kill вызывается без какого-либо параметра, он отправляет номер сигнала 15 (SIGTERM). Процесс может быть проигнорирован этим сигналом. Этот сигнал уведомляет процесс, чтобы очистить его вещи, а затем закончить сам. Это хороший способ.
Вы также можете «отправить» номер сигнала 9 (SIGKILL), который не может быть проигнорирован процессом. Этот процесс даже не распознает его, потому что ядро завершает процесс, а не сам процесс. Это хороший способ.
Говорят, что kill -9 <pid> всегда работает. Это неверное мнение. Бывают ситуации, когда даже kill -9 не убивает процесс. Например, когда процесс имеет состояние D (непрерывный сон). Процесс приходит в это состояние каждый раз, когда он ждет ввода-вывода (обычно не очень долго). Итак, если процесс ожидает ввода-вывода (например, на жестком диске дефекта), и он не запрограммирован должным образом (с таймаутом), вы просто не можете убить процесс. Не важно, что вы делаете. Вы можете попытаться сделать файл доступным, чтобы процесс продолжался.
-
1Это очень полезно, я испытал это несколько раз из-за зависания доступа ввода / вывода на сетевых дисках, и мне было интересно, почему я не смог убить процессы, которые застыли. Есть ли больше документации по этой конкретной проблеме и как обойти ее? – Sheljohn 7 July 2014 в 01:13
Несмотря на то, что это имя убивает, на самом деле не убивает процессы, он посылает на него сигналы. На странице man:
kill - send a signal to a process
Сигналом по умолчанию, отправленным kill [pid], является SIGTERM, который обычно, но не обязательно, требует завершения процесса. Вполне возможно написать программу, которая играет счастливую мелодию, когда вы посылаете на нее сигнал SIGTERM, но не рекомендуется.
Другим распространенным сигналом является SIGTERM , который часто используется для запроса программа для перечитывания своих файлов конфигурации.
Если вы действительно хотите убить программу, вам нужно использовать сигнал SIGKILL, выполнив kill -9 [pid].
Похоже, вы можете приостановить процесс (возможно, нажав Ctrl-Z в терминале). В этом состоянии ваш процесс не будет реагировать на SIGTERM, поскольку он заморожен. Запуск «fg» оттаивает процесс, поэтому он может подхватывать сигнал и автоматически останавливаться. Это может объяснить, почему «fg», похоже, обновляет список процессов.
-
1
Изнутри C ++ я выполнил:
kill(4024, SIGKILL);
И на терминале linux (Ubuntu),
$ ps -ax | grep my_su
Выход был:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Кажется, он (4024) все еще выживает. Однако, как только я прекратил родительский процесс, который вызвал вышеупомянутый оператор «kill», 4024 больше не появлялся. Теперь я сужу «несуществующий» процесс - это не что иное, как отображаемая строка, и решил проигнорировать ее. Надеюсь, мой опыт может помочь кому-то там. Ура!