Что делать, если «kill -9» не работает?

У меня есть процесс, который я не могу убить с помощью kill -9 <pid>. В чем проблема в этом случае, тем более что я являюсь владельцем этого процесса. Я думал, что ничто не может уклониться от этой опции kill.

412 голосов | спросил Tshepang 10 Jpm1000000pmMon, 10 Jan 2011 22:51:43 +030011 2011, 22:51:43

13 ответов


491

kill -9 ( SIGKILL ) всегда работает, если у вас есть разрешение убить процесс. В принципе, процесс должен запускаться вами, а не быть setuid или setgid, или вы должны быть root. Существует одно исключение: даже root не может отправить фатальный сигнал PID 1 (процесс init).

Однако kill -9 не гарантируется немедленное выполнение . Все сигналы, включая SIGKILL, поставляются асинхронно: ядро ​​может занять некоторое время, чтобы доставить их. Как правило, передача сигнала занимает не более нескольких микросекунд, а всего лишь времени, затрачиваемого на достижение цели. Однако, если цель заблокировала сигнал , сигнал будет поставлен в очередь, пока target разблокирует его.

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

Процесс, заблокированный в системном вызове, находится в бесперебойном сне . Команда ps или top будет (в большинстве униформ) показывать ее в состоянии D (первоначально для d iskâ €, я думаю).

Классическим случаем длительного непрерывного сна является процесс доступа к файлам через NFS , когда сервер не отвечает ; современные реализации, как правило, не навязывают непрерывный сон (например, в Linux, параметр mount intr позволяет сигналу прерывать доступ к файлам NFS).

Иногда вы можете видеть записи, помеченные Z (или H в Linux, я не знаю, что такое различие) в ps или top. Это технически не процессы, они являются зомби-процессами, которые представляют собой не что иное, как запись в таблице процессов, которая поддерживается так, чтобы родительский процесс мог быть уведомлен о смерти его ребенка. Они исчезнут, когда родительский процесс обратит внимание (или умрет).

ответил Gilles 10 Jpm1000000pmMon, 10 Jan 2011 23:08:45 +030011 2011, 23:08:45
88

Когда-нибудь процесс существует и не может быть убит из-за:

  • - зомби. То есть который родитель не прочитал статус выхода. Такой процесс не потребляет никаких ресурсов, кроме записи ПИД. В top отображается сообщение Z
  • ошибочный бесстрашный сон. Это не должно происходить, но с комбинацией из-за ошибок кода ядра и /или неисправного оборудования, которое это когда-то делает. Единственный метод - перезагрузка или ожидание. В top он сигнализирует D.
ответил Maciej Piechotka 10 Jpm1000000pmMon, 10 Jan 2011 23:03:39 +030011 2011, 23:03:39
31

Похоже, у вас может быть процесс зомби . Это безобидно: единственный ресурс, который использует зомби-процесс, - это запись в таблице процессов. Он исчезнет, ​​когда родительский процесс умирает или реагирует на смерть его ребенка.

Вы можете увидеть, является ли этот процесс зомби, используя top или следующую команду:

ps aux | awk '$8=="Z" {print $2}'
ответил Josh 10 Jpm1000000pmMon, 10 Jan 2011 23:02:08 +030011 2011, 23:02:08
24

Проверьте ваши /var/log/kern.log и /var/log/dmesg (или эквиваленты) для любых подсказок. По моему опыту, это случилось со мной только тогда, когда сетевое подключение монтирования NFS неожиданно упало или произошел сбой драйвера устройства. Возможно, произойдет и сбой жесткого диска. Я уверен.

Вы можете использовать lsof, чтобы узнать, какие файлы устройств открыт.

ответил LawrenceC 11 Jpm1000000pmTue, 11 Jan 2011 17:41:12 +030011 2011, 17:41:12
17

Если @ Maciej и @ Ответы Gilles не решают вашу проблему , и вы не узнаете процесс (и спрашиваете, что у вас с вашим дистрибутивом, не получается ответов). Проверьте наличие Rootkit и других признаков того, что вы были . Руткит более чем способен предотвратить вас от убийства процесса. На самом деле многие способны помешать вам увидеть их. Но если они забывают изменить одну небольшую программу, они могут быть замечены (например, они модифицировали top, но не htop)). Скорее всего, это не так, но лучше безопасно, чем жаль.

ответил xenoterracide 11 Jpm1000000pmTue, 11 Jan 2011 12:57:11 +030011 2011, 12:57:11
11

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

При отправке сигнала приложение использует его. если не ядро ​​имеет дело с ним. поэтому вы можете захватить сигнал в своем приложении.

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

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

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

ответил DeveloperChris 11 Jam1000000amTue, 11 Jan 2011 05:01:19 +030011 2011, 05:01:19
10

Сначала проверьте, является ли его зомби-процесс (что очень возможно):

ps -Al

Вы увидите что-то вроде:

0 Z  1000 24589     1  0  80   0 -     0 exit   ?        00:00:00 soffice.bin <defunct>

(Обратите внимание на «Z» слева)

Если пятый столбец не равен 1, значит, он имеет родительский процесс. Попробуйте убить этот родительский идентификатор процесса .

Если его PPID = 1, НЕ УБИТЬ ЭТО !! , подумайте, какие другие устройства или процессы могут быть связаны с ним.

Например, если вы использовали смонтированное устройство или samba, попробуйте отключить его. Это может освободить процесс Zombie.

ответил lepe 8 +04002013-10-08T12:32:06+04:00312013bEurope/MoscowTue, 08 Oct 2013 12:32:06 +0400 2013, 12:32:06
9

Как отмечали другие, процесс в режиме бесперебойного сна не может быть немедленно убит (или, в некоторых случаях, вообще). Стоит отметить, что для решения этой проблемы в некоторых сценариях добавлено другое состояние процесса TASK_KILLABLE, в частности, обычный случай, когда процесс ожидает NFS. См. http://lwn.net/Articles/288056/

К сожалению, я не считаю, что это используется в любом месте ядра, но NFS.

ответил 28 MaramThu, 28 Mar 2013 09:51:33 +04002013-03-28T09:51:33+04:0009 2013, 09:51:33
8

Вы написали свой собственный процесс, так что мой ответ немного не соответствует теме, но для записи обратите внимание, что процесс init невосприимчив к SIGKILL.

ответил jlliagre 12 Jam1000000amWed, 12 Jan 2011 00:42:49 +030011 2011, 00:42:49
6

Сделал небольшой скрипт, который очень помог мне взглянуть!

Вы можете использовать его, чтобы убить любой процесс с заданным именем на своем пути (обратите внимание на это !!) Или вы можете убить любой процесс данного пользователя, используя параметр «-u username».

#!/bin/bash

if [ "$1" == "-u" ] ; then\n
        PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
        processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
        echo "############# Killing all processes of user: $2 ############################"
else
        echo "############# Killing processes by name: $1 ############################"
        processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi


for process in $processes ; do
        # "command" stores the entire commandline of the process that will be killed
        #it may be useful to show it but in some cases it is counter-productive
        #command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
        echo "Killing process: $process"
        echo ""
        kill -9 $process
done
ответил user36035 28 MaramThu, 28 Mar 2013 00:49:29 +04002013-03-28T00:49:29+04:0012 2013, 00:49:29
5

Есть случаи, когда даже если вы отправите kill -9 в процесс, этот pid остановится, но процесс перезапустится автоматически (например, если вы попробуете его с помощью gnome-panel), перезапустится): может ли это быть здесь?

ответил dag729 12 Jam1000000amWed, 12 Jan 2011 02:16:57 +030011 2011, 02:16:57
2

из здесь изначально :

проверить, показывает ли strace что-либо

strace -p <PID>

попробуйте подключиться к процессу с помощью gdb

gdb <path to binary> <PID>

, если процесс взаимодействует с устройством, которое вы можете размонтировать, удалить модуль ядра или физически отключить /отключить ... затем попробуйте это.

ответил nmz787 18 MaramSat, 18 Mar 2017 10:30:21 +03002017-03-18T10:30:21+03:0010 2017, 10:30:21
0

У меня была такая проблема. Это была программа, которую я запускал с помощью strace и прервался с помощью Ctrl + C. Он закончился в состоянии T (отслеживание или остановка). Я не знаю, как это произошло точно, но это не было уничтожено с помощью SIGKILL.

Короче говоря, мне удалось убить его с помощью gdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit
ответил Christophe Drevet-Droguet 29 Maypm18 2018, 16:16:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132