Кто в ядре отвечает за убийство процесса.
Что делать, если приходит «kill», а процесс находится в заблокированном состоянии. Убивает ли ожидание, пока процесс перейдет в рабочее состояние, чтобы очистить себя.
Если кто-то может ответить больше с точки зрения ядра, например, когда генерируется SIGINT из команды kill, все что вызывается ядром до тех пор, пока TCB (блоки управления задачами) не будут очищены в конце.
Я предполагаю, что вы говорите о SIGKILL, поэтому я ограничусь обсуждением только этого сигнала.
Когда процесс вызывает SIGKILL для другого процесса, SIGKILL добавляется в качестве ожидающего сигнала для процесса-жертвы, и все ожидающие сигналы SIGSTOP, SIGTSTP, SIGTTOU или SIGTTIN очищаются. Жертва просыпается (становится работоспособной), если она остановлена или находится в состоянии прерывистого сна.
Когда процесс-жертва в следующий раз пытается перейти из режима ядра в режим пользователя, ожидающие сигналы проверяются. Здесь находится ожидающий SIGKILL, и ядро вызывает do_exit () вместо возврата в пользовательский режим.
Переход из режима ядра в режим пользователя произойдет при следующем планировании процесса (если только он не находился в непрерывном спящем режиме - это печально известное состояние D). Если он находится в непрерывном сне, процесс не будет пытаться вернуться в пользовательский режим, пока не проснется.
Удаление его с помощью сигнала, отличного от SIGKILL, просто вызывает отправку сигнала. Это может быть замаскировано или проигнорировано, но если это не так (или после того, как оно разоблачено), то это прерывает нормальное выполнение программы.
Если выполняется системный вызов типа IPC (например, чтение из сокета, select (), poll (), sleep () и т. Д.), Он будет прерван и завершится ошибкой с EINTR в errno. Правильно написанное приложение повторно вызовет вызов после обработки сигнала.
Затем процесс немедленно выполняет вызов обработчика сигнала, который может вернуться, чтобы разрешить продолжение обработки, или он может вызвать longjmp (в C), или он может выйти из процесса, что обычно является значением по умолчанию.
SIGKILL совершенно другой, ничего из вышеперечисленного не происходит. Вместо этого он просто завершает системный вызов (который, вероятно, оставит EINTR в errno, если процессу было разрешено его прочитать), а затем вызывает немедленный выход задачи без возможности ее обработки.
Но я думаю, что любой из них ждет завершения состояния «D» «непрерывный сон». Обычно это может быть что-то вроде чтения с блокирующего диска, загрузки с ошибкой страницы или чего-то подобного.
SIGSTOP также нельзя замаскировать или игнорировать.
- person ephemient; 10.07.2009
EINTR не возвращается, если вы не установили обработчики сигналов прерывания, используя sigaction с опущенным флагом SA_RESTART, или если функция signal вашей системы прерывает работу по умолчанию (это не в нормальных системах, таких как Linux и BSD).
- person R.. GitHub STOP HELPING ICE; 01.02.2011
Запуск kill просто посылает процессу сигнал (TERM) с просьбой завершить его. Если не ответит, это дело. Однако вы можете отправить любой из нескольких разных сигналов, приказывающих ему Уходите. Что вас может заинтересовать, так это kill -9 (SIGKILL), которая убивает его, не давая ему выбора в этом вопросе.
(Изменить: как было указано в комментариях, TERM по умолчанию)
kill по умолчанию отправляет SIGTERM, который является сигналом для завершения, а не SIGINT
- person Christoffer Hammarström; 03.02.2012
Уничтожение (а не прерывание) обычно выполняется сигналом SIGKILL в системах UNIX (CTRL-C отправляет SIGINT).
Эти системы обычно предоставляют метод прерывания блокирующих системных вызовов сигналом, который позволяет обработчику сигнала выполняться, не дожидаясь завершения системного вызова (здесь возникает ошибка EINTR). Итак, обычно вызов просто отменяется, не дожидаясь его завершения.
Каждый процесс может получать много типов сигналов, которые он может игнорировать для обработки, но некоторые из них не доставляются процессу, но «Планировщик процессов» завершает процесс .... см. Здесь http://www.linux-tutorial.info/modules.php?name=MContent&pageid=289
