Как работает «убить»? И, в частности, как "kill" работает на заблокированном процессе? - PullRequest
2 голосов
/ 10 июля 2009

Кто в ядре отвечает за уничтожение процесса.

Что если произойдет «kill» и процесс находится в заблокированном состоянии. Ждет ли kill, пока процесс не придет в рабочее состояние, чтобы очистить себя.

Если кто-то может ответить больше с точки зрения ядра, например, когда генерируется SIGINT из команды kill, что все вызывается ядром, пока TCB (блоки управления задачами) не будут очищены в конце.

Ответы [ 5 ]

7 голосов
/ 10 июля 2009

Полагаю, вы говорите о SIGKILL, поэтому я ограничусь обсуждением только этим сигналом.

Когда процесс вызывает SIGKILL для другого процесса, SIGKILL добавляется в качестве ожидающего сигнала для процесса-жертвы, и все ожидающие сигналы SIGSTOP, SIGTSTP, SIGTTOU или SIGTTIN очищаются. Жертва просыпается (становится работоспособной), если она остановлена ​​или находится в состоянии прерывистого сна.

Когда следующий процесс жертвы пытается перейти из режима ядра в режим пользователя, ожидающие сигналы проверяются. Здесь находится ожидающий SIGKILL, и ядро ​​вызывает do_exit () вместо возврата в режим пользователя.

Переход из режима ядра в режим пользователя будет выполнен при следующем планировании процесса (если только он не находился в непрерывном режиме сна - это печально известное состояние D). Если он находится в непрерывном режиме сна, процесс не будет пытаться вернуться в режим пользователя до тех пор, пока он не разбудит.

5 голосов
/ 10 июля 2009

Убивая его сигналом, отличным от SIGKILL, просто вызывает отправку сигнала. Это может быть замаскировано или проигнорировано, но при условии, что это не так (или после того, как оно снято), оно прерывает нормальный запуск программы.

Если выполняется системный вызов IPC-типа (например, чтение из сокета, select (), poll (), sleep () и т. Д.), Он будет прерван и завершится ошибкой с EINTR по ошибке. Правильно написанное приложение повторно выполнит вызов после обработки сигнала.

Затем процесс немедленно выполняет вызов обработчику сигнала, который может вернуться, чтобы продолжить обработку, или вызвать longjmp (на C), или выйти из процесса, что обычно является значением по умолчанию.

SIGKILL совершенно другой, ничего из вышеперечисленного не происходит. Вместо этого он просто завершает системный вызов (который, по-видимому, оставил бы EINTR в состоянии errno, если бы процессу было разрешено его прочитать), а затем немедленно завершает задачу, не имея возможности обработать его.

Но любой из них, я думаю, ждет завершения состояния "D" "непрерывного сна". Обычно это что-то вроде блокировки диска при чтении, загрузки страницы по требованию или что-то в этом роде.

1 голос
/ 10 июля 2009

Запуск kill просто отправляет процессу (TERM) сигнал с просьбой прекратить его. Если он не ответит, то это бизнес. Тем не менее, вы можете отправить любой из нескольких разных сигналов , требующих его удаления. Что вас может заинтересовать, так это kill -9 (SIGKILL), который убивает его, не давая ему выбора в этом вопросе.

(Изменить: как было отмечено в комментариях, TERM является значением по умолчанию)

0 голосов
/ 10 июля 2009

Каждый процесс может получать сигналы разных типов, которые он может игнорировать, но немногие не доставляются процессу, но «Планировщик процесса» завершает процесс .... см. это для большего объяснения http://www.linux -tutorial.info / modules.php? Имя = MContent & PageId = 289

0 голосов
/ 10 июля 2009

Уничтожение (а не прерывание) обычно выполняется сигналом SIGKILL в системах UNIX (CTRL-C отправляет SIGINT).

Эти системы обычно предоставляют метод прерывания блокировки системных вызовов сигналом, который позволяет обработчику сигнала выполняться без ожидания завершения системного вызова (в этом случае возникает ошибка EINTR). Так что обычно , вызов просто отменен, не дожидаясь его завершения.

...