Когда я не должен убивать процесс?

401

Я всегда очень не решаюсь бежать kill -9, но я вижу, что другие администраторы делают это почти постоянно.

Я полагаю, что есть разумная золотая середина, поэтому:

  1. Когда и почему следует kill -9использовать? Когда и почему нет?
  2. Что нужно попробовать, прежде чем делать это?
  3. Какая отладка «зависшего» процесса может вызвать дальнейшие проблемы?
Mikel
источник
7
Хороший связанный ответ ТАК .
jw013

Ответы:

362

Как правило, вы должны использовать kill(сокращение kill -s TERMили в большинстве систем kill -15) перед kill -9( kill -s KILL), чтобы дать целевому процессу возможность очиститься после себя. (Процессы не могут перехватить или проигнорировать SIGKILL, но они могут и часто делают перехват SIGTERM.) Если вы не дадите процессу возможность завершить то, что он делает, и очистить, он может оставить поврежденные файлы (или другое состояние) вокруг него. не сможет понять, после перезагрузки.

strace/ truss, ltraceи, gdbкак правило, хорошие идеи, чтобы посмотреть, почему застрял процесс. ( truss -uв Solaris это особенно полезно; я считаю, что ltraceслишком часто приводятся аргументы для вызовов библиотеки в непригодном для использования формате.) В Solaris также есть полезные /procинструменты, некоторые из которых были перенесены в Linux. ( pstackчасто полезно).

geekosaur
источник
67
веская причина в том, что если вы привыкли посылать SIGKILL, то, когда вы попадете в программу, которая, например, испортит важную для вас или вашей компании базу данных, вы действительно пожалеете об этом. kill -9имеет свое применение как терминатор последней инстанции, акцент на последней инстанции; администраторы, которые используют его перед последним средством а) не слишком хорошо понимают, что такое администратор, и б) не должны быть в производственной системе.
Arcege
9
@Mikel Еще одна вещь, через которую можно пройти, иногда лучше заставить приложение очистить себя с помощью сигнала типа SIGQUIT или SIGSEGV, если оно не отвечает на SIGINT / SIGTERM. Например, полноэкранное 3-D приложение или даже Xorg. Используя SIGQUIT, у него не будет возможности что-то очистить, но он обманом заставит думать, что произошла ошибка сегмента, и он будет чувствовать, что у него нет другого выбора, кроме как очистить и выйти.
penguin359
12
@Arcege Считаете ли вы, что использование базы данных, которая повреждает данные при уничтожении с помощью -9, в конце концов, стоит использовать? iirc, mysql, bdb, pg и т.д ... все ведут себя хорошо, когда их убивают с -9.
dhruvbird
13
killall -9 java ftw
dmourati
23
@dhruvbird: то, что ваши БД должны быть оснащены бронежилетами, не означает, что вы должны стрелять в них, если вам это не нужно. Хотя вы, возможно, и правы, что это не так рискованно, как, кажется, говорит Арцеж, но я думаю, что его точка зрения остается неизменной, что это рискованно и должно быть последним средством.
иконоборчество
228

Рэндал Шварц часто публиковал «Бесполезное использование (x)» в списках. Один такой пост был о kill -9. Это включает причины и рецепт, чтобы следовать. Вот реконструированная версия (цитируется ниже).

(Цитата мерзость)

Нет нет нет. Не используйте kill -9.

Это не дает процессу возможность чисто:

1) отключить разъемы

2) очистить временные файлы

3) сообщить своим детям, что он уходит

4) сбросить свои терминальные характеристики

и так далее, и так далее, и так далее.

Как правило, отправьте 15 и подождите секунду или две, и если это не сработает, отправьте 2, а если это не сработает, отправьте 1. Если это не сработает, УДАЛИТЕ ДВОЙНОЙ, потому что программа плохо себя ведет!

Не используйте kill -9. Не берите комбайн только для того, чтобы привести в порядок цветочный горшок.

Просто еще одно бесполезное использование Usenet,

(.подпись)

Шон Дж. Гофф
источник
12
Не закроет ли операционная система какие-либо дескрипторы открытых файлов (включая сокеты), когда процесс завершится?
Брайан Гордон
3
Да, это будет. Но предположим, что вы убиваете процесс сервера с подключенными клиентами, тогда клиенты не заметят, что сервер пропал до истечения времени ожидания.
Бьорн Линдквист
45
Ах, да, старый аргумент "если он каким-то образом несовершенен, вы глупы его использовать".
Timmmm
3
Или глупо использовать, если рассматриваемый процесс является производством вашей компании
Уоррен П
3
Если процесс завершен, сокет отправит RST равноправному узлу, где, как будто процесс вызывает закрытие или завершение работы сокета, сокет отправляет FIN. Нет необходимости в тайм-ауте. Ситуация тайм-аута произойдет, только если будет отключено питание или удален сетевой кабель.
Ctrl-Alt-Delor
78

Это всегда должно быть в порядке kill -9, точно так же, как всегда должно быть в порядке, чтобы отключиться, потянув за кабель питания. Это может быть антиобщественным и оставить некоторое восстановление, но это должно сработать, и это мощный инструмент для нетерпеливых.

Я говорю это как кто-то, кто сначала попробует обычный kill (15), потому что он дает программе шанс выполнить некоторую очистку - возможно, просто записывает в журнал «выход на sig 15». Но я не приму никаких жалоб на плохое поведение при убийстве -9.

Причина: многие клиенты делают это с тем, что программисты предпочли бы, а затем нет. Случайное уничтожение -9 - это хороший и честный тестовый сценарий, и если ваша система не справляется с этим, ваша система сломана.

dbrower
источник
2
Как вы проверяете «случайное убийство -9»? Когда вы получаете убить -9, вы сделали и закончили.
Карел Билек
18
@Karel: Вы проверяете, может ли ваша система впоследствии восстановиться, и очищаете любые искаженные транзакции, которые обрабатывались во время SIGKILL.
Тадеуш А. Кадлубовски
7
Это не нормально делать так kill -9же, как это не в порядке, чтобы вытащить вилку. Хотя, конечно, бывают ситуации, когда у вас нет выбора, это должно быть последнее действие. Конечно, отсоединение кабеля питания kill -9не должно иметь негативных последствий, таких как предотвращение перезапуска приложения или ОС, если это вообще происходит, но дерьмо случается и использование рекомендуемых способов ( kill [-15]) или регулярное отключение поможет избежать беспорядка, который может возникнуть, если Вы регулярно прерываете программы и операционные системы таким образом. В любом случае всегда существует риск потери данных независимо от надежности кода.
Jlliagre
7
Я подозреваю, что Майкл имел в виду под «ОК», что ваша программа должна корректно справиться с этой ситуацией и иметь возможность выполнить некоторую форму очистки при перезапуске. Например, очистка PID-файлов и так далее, а не просто выбрасывание игрушек из коляски и отказ от запуска.
gerryk
2
@gerryk Они действительно должны, но проблема в том, что некоторые люди воспримут этот ответ как «лицензию на убийство -9» независимо от ситуации и окружающей среды. Это безответственное отношение.
Jlliagre
39

Я использую kill -9 почти так же, как я бросаю кухонные инструменты в посудомоечную машину: если кухонный инструмент разрушен посудомоечной машиной, то я не хочу этого.

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

Потому что в реальном мире все может ухудшиться в любое время по любой причине.

Люди должны писать программное обеспечение, которое терпимо к сбоям. В частности на серверах. Вы должны научиться проектировать программное обеспечение, которое предполагает, что что-то сломается, сломается и т. Д.

То же самое касается настольного программного обеспечения. Когда я хочу выключить свой браузер, обычно требуется ВОЗРАСТ, чтобы выключиться. Там нет ничего моего браузера нужно сделать , что следует принимать более не более чем несколько секунд. Когда я прошу его закрыть, он должен сделать это немедленно. Если этого не произойдет, тогда мы вытащим kill -9 и сделаем это.

Borud
источник
4
Я согласен, что процесс должен быть написан так, чтобы быть терпимым к такой неудаче, но я думаю, что это все еще плохая практика. База данных будет восстановлена, но она может обнаружить грубое прерывание и затем инициировать значительную проверку восстановления при перезапуске. А как насчет запросов, которые обслуживает процесс? Все они будут немедленно разорваны, у клиентов могут быть ошибки и ошибки тоже?
Дэниел Джеймс Брайарс
3
База данных, которая не может быть уничтожена в любое время, не является надежной базой данных. Это довольно основное требование, если вам требуется последовательность. Что касается клиентов: если они разоряются и портят данные при разрыве соединения, они также плохо спроектированы. Способ решения проблемы потери обслуживания - через стратегии резервирования и автоматического восстановления после отказа / повторной попытки. Обычно для большинства систем быстрый сбой предпочтительнее, чем попытка восстановления.
Боруд
4
@borud Это может быть не совсем написанное программное обеспечение, но это программное обеспечение, которое люди используют постоянно. Какие системные администраторы могут позволить себе всегда выбирать программное обеспечение, которое идеально написано, и всегда корректно восстанавливаться после внезапного сбоя? Не много. Лично я использую сценарии завершения работы и запускаю / останавливаю процессы через это. Если они не реагируют на сценарий завершения работы (который правильно сигнализирует процессу), я убиваю -9.
Стив Сетер
2
Нет разницы между приготовлением простых блюд и более сложных блюд в отношении инструментов. Разница в поваре. (Однако, если вы тратите столько же времени на приготовление пищи, сколько и я, вы понимаете, что надежность - это минимальное требование к кухонным инструментам и что большинство людей, которые продают кухонные принадлежности потребителям, не знают плохого инструмента из отличного инструмента.)
борул
1
Таким образом, вы поощряете людей быть небрежными, потому что это трудно сделать правильно? Все больше и больше программного обеспечения запускается в операционных средах, которые эфемерны. Если вы пишете программное обеспечение, которое становится суетливым, если оно не закрывается должным образом, вам будет трудно убедить работодателей нанять вас в качестве разработчика.
Боруд
10

Во всех остальных ответах не упоминается случай, когда он kill -9вообще не работает, когда процесс не <defunct>может быть остановлен:

Как я могу убить процесс <defunct>, чьим родителем является init?

Что такое несуществующий процесс и почему его не убивают?

Поэтому , прежде чем пытаться kill -9в <defunct>процессе запуска , ps -efчтобы увидеть , что его родитель и попытаться -15(TERM) или -2(INT) и , наконец -9(сразит) на его родителей.

Примечание: что ps -efделает .

Дальнейшее редактирование и предостережение: Будьте осторожны, когда убиваете процессы, их родителей или их потомков, потому что они могут оставлять файлы открытыми или поврежденными, соединения незавершенными, могут повреждать базы данных и т. Д., Если вы не знаете, что kill -9нужно для процесса, используйте его только в качестве крайней меры и, если вам нужно запустить kill, используйте сигналы, указанные выше, перед использованием-9 (KILL)

Эдуард Флоринеску
источник
6

Никогда никогда не делай kill -9 1. Также избегайте уничтожения некоторых процессов, таких как mount`. Когда мне нужно убить много процессов (скажем, например, зависает X-сессия, и мне нужно убить все процессы определенного пользователя), я меняю порядок процессов. Например:

ps -ef|remove all processes not matching a certain criteria| awk '{print $2}'|ruby -e '$A=stdin.readlines; A.reverse.each{|a| puts "kill -9 #{a}"}'|bash

Имейте в виду, что killне останавливает процесс и не высвобождает его ресурсы. Все, что он делает, это посылает сигнал SIGKILL процессу; Вы можете закончить процесс, который зависает.

HandyGandy
источник
1
Пониженный голос был кем-то еще. Но какие ресурсы не освобождаются? Вы хотите сказать, что процесс не может выполнить свою обычную очистку? А как насчет файловых блокировок, семафоров и т. Д.? Можете ли вы уточнить?
Микель
Похоже, что общая память SysV и семафоры должны быть очищены, по крайней мере. archives.postgresql.org/pgsql-general/2006-10/msg01065.php
Микель,
8
Этот ответ является частично запутанным и частично неправильным. kill -9 1просто игнорируется под большинством юнитов. Там нет необходимости , чтобы избежать kill -9для mount, но нет смысла в нем тоже. Я не знаю, что вы подразумеваете под «обратным порядком процессов». kill -9действительно останавливает (как, например, уничтожает) процесс, не давая ему возможности пожаловаться, однако уничтожение не произойдет немедленно, если процесс находится в непрерывном системном вызове . Уничтожение процесса kill -9освобождает большинство ресурсов, но не все .
Жиль
5

Убийство процессов волей-неволей не гладкое движение: данные могут быть потеряны, плохо спроектированные приложения могут незаметно сломаться, что не может быть исправлено без переустановки ... но это полностью зависит от знания того, что и что небезопасно в данная ситуация. и что будет в опасности. Пользователь должен иметь некоторое представление о том, что делает или должен делать процесс и каковы его ограничения (дисковые операции ввода-вывода в секунду, rss / swap) и уметь оценивать, сколько времени должен занимать длительный процесс (например, копия файла, перекодирование в mp3, перенос электронной почты, резервное копирование, [ваш любимый таймсинк здесь].)

Кроме того, отправка SIGKILLpid не гарантирует его уничтожения. Если он застрял в системном вызове или уже зомбирован ( Zв ps), он может продолжать зомбироваться. Это часто случается с ^ Z длительным процессом и забывающим, bgпрежде чем пытаться kill -9это сделать. Простое fgпереподключение stdin / stdout и, возможно, разблокирование процесса, обычно после чего процесс завершается. Если он застрял в другом месте или в какой-либо другой форме тупика ядра, удалить его сможет только перезагрузка. (Процессы Zombie уже мертвы после того, SIGKILLкак обработаны ядром (дальнейший код пользователя не запускается), обычно есть причина в ядре (похожая на «блокировку» в ожидании завершения системного вызова) для завершения процесса.)

Кроме того, если вы хотите убить процесс и все его дочерние элементы, привыкните к вызову killс использованием отрицательного PID, а не только самого PID . Там нет никакой гарантии SIGHUP, SIGPIPEили SIGINTдругих сигналов очистки после него, и раздражает наличие нескольких процессов для очистки (помните, монгрел?).

Бонусное зло: kill -9 -1немного более разрушительно, чем kill -9 1(Не делайте ни от имени root, если вы не хотите видеть, что происходит на одноразовой, неважной виртуальной машине)

dhchdhd
источник
3

Почему вы не хотите, чтобы kill -9процесс нормально

По словам man 7 signal:

Сигналы SIGKILL и SIGSTOP не могут быть пойманы, заблокированы или проигнорированы.

Это означает, что приложение, которое получает любой из этих сигналов, не может «перехватить» их, чтобы выполнить какое-либо поведение при завершении работы.

Что вы должны сделать перед запуском kill -9процесса

Перед отправкой сигнала процессу вы должны убедиться, что вы:

  1. Убедитесь, что процесс не занят (т.е. выполняет «работу»); отправка kill -9в процесс по существу приведет к потере этих данных.
  2. Если процесс является неотзывчивой базой данных, убедитесь, что он сначала очистил свои кэши. Некоторые базы данных поддерживают отправку других сигналов процессу для принудительной очистки его кэша.

источник
3

Я создал скрипт, который помогает автоматизировать эту проблему.

Это основано на моем полном ответе 2 на вопрос, очень похожий на stackoverflow .

Вы можете прочитать все объяснения там. Подводя итог, я бы порекомендовал просто SIGTERMи SIGKILL, или даже SIGTERM, SIGINTи SIGKILL. Однако я даю больше вариантов в полном ответе.

Пожалуйста, не стесняйтесь скачать (клонировать) его из хранилища GitHub, чтобы убить изящно 1

Доктор Беко
источник