Коли я не повинен вбивати -9 процес?

Я завжди дуже вагаюся бігати kill -9, але бачу, що інші адміністратори роблять це майже звичайно.

Я вважаю, що, мабуть, є розумний середина, так що:

1. Коли і навіщо kill -9їх використовувати? Коли і чому ні?
2. Що слід спробувати, перш ніж це зробити?
3. Яка налагодження "підвішеного" процесу може спричинити подальші проблеми?

Як правило, вам слід скористатися 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часто корисна).

Рандаль Шварц часто публікував "Марно використання (x)" у списках. Один такий пост був о kill -9. Він включає причини і рецепт, який слід дотримуватися. Ось реконструйована версія (цитується нижче).

(Цитата гидоти)

Ні-ні-ні. Не використовуйте kill -9.

Це не дає процесу чисто:

1) відключити розетки

2) очищення тимчасових файлів

3) повідомити своїх дітей, що вона йде

4) скинути його термінальні характеристики

і так далі, і так далі, і так далі.

Як правило, надішліть 15, і зачекайте секунду-дві, і якщо це не працює, надішліть 2, а якщо це не працює, надішліть 1. Якщо цього не відбувається, ВИДАЛУЙТЕ БІННЯР, оскільки програма погано ведеться!

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

Ще одне марне використання Usenet,

(. підпис)

Це має бути завжди в порядку kill -9, як і завжди повинно бути гаразд до відключення, потягнувши кабель живлення. Це може бути антисоціальним і залишати певне відновлення, але воно повинно працювати, і є силовим інструментом для нетерплячих.

Я говорю це як хтось, хто спробує вбити звичайний (15) спершу, тому що це дає програмі шанс зробити деяку очистку - можливо, просто записати в журнал "виходить на сиг 15". Але я не прийму жодної скарги на жорстоку поведінку вбивства -9.

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

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

Те саме стосується більшості програм (навіть баз даних): якщо я не можу їх убити без того, щоб вони перейшли, я не хочу їх використовувати. (І якщо вам трапляється використовувати одну з цих баз даних, яка спонукає вас робити вигляд, що вони зберігають дані, коли їх немає: ну, мабуть, саме час ви починаєте замислюватися над тим, що ви робите).

Тому що в реальному світі речі можуть зійти в будь-який час з будь-якої причини.

Люди повинні писати програмне забезпечення, яке терпимо до збоїв. Зокрема на серверах. Ви повинні навчитися розробляти програмне забезпечення, яке передбачає, що все зірветься, вийде з ладу тощо.

Те саме стосується програмного забезпечення для настільних ПК. Коли я хочу вимкнути браузер, його зазвичай потрібно відключити. Там немає нічого мого браузера потрібно зробити , що слід приймати більше не більше ніж кілька секунд. Коли я прошу його закрити, мені слід це зробити негайно. Коли це не так, тоді ми витягуємо вбивство -9 і встигаємо.

Не згадується в усіх інших відповідях - це випадок, коли він kill -9взагалі не працює, коли процес є <defunct>і не може бути знищений:

Як я можу вбити процес <defunct>, батьком якого є init?

Що є несправним для процесу і чому його не вбивають?

Тому , перш ніж намагатися kill -9в <defunct>процесі запуску , ps -efщоб побачити , що його батько і спробувати -15(TERM) або -2(INT) і , нарешті -9(уб'є) на його батьків.

_{Примітка: що ps -efробить .}

_{Пізніше редагуйте та обережно: Дійте обережно, коли вбиваєте процеси, їх батьків чи своїх дітей, оскільки вони можуть залишати файли відкритими або пошкодженими, з'єднання незавершеними, можуть пошкодити бази даних тощо, якщо ви не знаєте, що kill -9стосується певного процесу, використовуйте його лише в крайньому випадку , і якщо вам потрібно запустити kill, перед використанням використовуйте вказані вище сигнали-9 (KILL)}

Ніколи ніколи не роби 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 процесу; ви можете завершити процес, який висів.

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

Крім того, надсилання SIGKILLпіда не є гарантією його вбивства. Якщо він застряг у системному дзвінку або вже зомбізований ( Zв ps), він може продовжувати зомбі. Часто це стосується ^ Z тривалий запущений процес і забуття, bgперш ніж спробувати kill -9його. Простий fgпідключить stdin / stdout і, ймовірно, розблокує процес, як правило, після цього процес закінчується. Якщо він застряг в іншому місці або в іншій формі тупикового ядра, вилучити процес може лише перезавантаження. (Процеси зомбі вже мертві після того SIGKILL, як ядро ​​обробляється (більше не буде запущений код користувача), зазвичай причина ядра (подібно до того, що "заблокована", очікуючи завершення системного виклику), щоб процес не завершився.)

Крім того, якщо ви хочете вбити процес та всіх його дітей, ввійдіть у звичку дзвонити killза допомогою заперечуваного PID, а не лише самого PID . Там немає ніякої гарантії SIGHUP, SIGPIPEабо SIGINTчи інші сигнали очищення після нього, і з купою відрікся процесів в очищенні (пам'ятаєте дворняга?) Дратує.

Бонусне зло: kill -9 -1трохи більше шкодить, ніж kill -9 1(Не робіть жодного як корінця, якщо ви не хочете бачити, що відбувається на викидній, неважливій ВМ)

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

Відповідно до man 7 signal:

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

Це означає, що програма, яка приймає будь-який з цих сигналів, не може «впіймати» їх, щоб виконувати будь-яку поведінку відключення.

Що слід зробити перед запуском kill -9процесу

Ви повинні переконатися, що перш ніж надсилати сигнал в процес, який ви:

1. Переконайтесь, що процес не зайнятий (тобто виконуючи "роботу"); надсилання в kill -9процес по суті призведе до втрати цих даних.
2. Якщо процес є невідповідальною базою даних, переконайтеся, що він спочатку промив кеші. Деякі бази даних підтримують надсилання інших сигналів до процесу, щоб примусити прошивати кеш.

Я створив сценарій, який допомагає автоматизувати цю проблему.

Він заснований на моїй повній відповіді 2 на запитання, дуже схоже на stackoverflow .

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

Будь ласка, не соромтесь завантажувати (клонуйте) його з сховища github, щоб вбити граціозно 1