Что, если 'уничтожают-9', не работает?

Я также использую:

export TERM=xterm-color
export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

И если Вам нравится колоризация Ваша подсказка, определенная, цветной Вар может быть полезным:

export COLOR_NC='\e[0m' # No Color
export COLOR_WHITE='\e[1;37m'
export COLOR_BLACK='\e[0;30m'
export COLOR_BLUE='\e[0;34m'
export COLOR_LIGHT_BLUE='\e[1;34m'
export COLOR_GREEN='\e[0;32m'
export COLOR_LIGHT_GREEN='\e[1;32m'
export COLOR_CYAN='\e[0;36m'
export COLOR_LIGHT_CYAN='\e[1;36m'
export COLOR_RED='\e[0;31m'
export COLOR_LIGHT_RED='\e[1;31m'
export COLOR_PURPLE='\e[0;35m'
export COLOR_LIGHT_PURPLE='\e[1;35m'
export COLOR_BROWN='\e[0;33m'
export COLOR_YELLOW='\e[1;33m'
export COLOR_GRAY='\e[0;30m'
export COLOR_LIGHT_GRAY='\e[0;37m'

И затем моя подсказка - что-то вроде этого:

case $TERM in
     xterm*|rxvt*)
         local TITLEBAR='\[\033]0;\u ${NEW_PWD}\007\]'
          ;;
     *)
         local TITLEBAR=""
          ;;
    esac

local UC=$COLOR_WHITE               # user's color
[ $UID -eq "0" ] && UC=$COLOR_RED   # root's color

PS1="$TITLEBAR\n\[${UC}\]\u \[${COLOR_LIGHT_BLUE}\]\${PWD} \[${COLOR_BLACK}\]\$(vcprompt) \n\[${COLOR_LIGHT_GREEN}\]→\[${COLOR_NC}\] "  

$ (vcprompt) называет сценарий Python в моем ~/sbin, который печатает информацию об управлении версиями о текущем пути. Это включает поддержку Подвижного, Мерзавца, Svn, Cvs, и т.д. У автора сценария есть источник здесь.

Bash prompt screenshot

Это - полный источник моей быстрой конфигурации:

484
26.08.2012, 13:37
14 ответов

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

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

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

Процесс, заблокированный в системном вызове, находится в бесперебойном сне. ps или top команда будет (на большинстве нельдов), показывают его в состоянии D (первоначально для “диска”, я думаю).

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

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

574
27.01.2020, 19:28
  • 1
    Yor сам противоречие. Вы начинаете говорить, что SIGKILL всегда работает, но конец, ссылающийся на бесперебойный прецедент сна, где SIGKILL никогда не мог бы работать, снаружи закрывая ядро. Существует также два случая, где SIGKILL не работает. С зомби, очевидно, поскольку Вы уже не можете уничтожить мертвые процессы и с init, который дизайном игнорирует сигналы SIGKILL. –  jlliagre 11.01.2011, 14:27
  • 2
    @jlliagre: Уничтожение зомби не имеет смысла, это не живо для начала. И уничтожение процесса в прерываемом сне действительно работает, это просто (как с другими сигналами) асинхронное. Я попытался разъяснить это в своем редактировании. –  Gilles 'SO- stop being evil' 11.01.2011, 22:07
  • 3
    , который я записал слишком уничтожающий зомби, не имеет смысла, но это не предотвращает многих людей, чтобы попробовать его и жаловаться. Уничтожение процесса в прерываемом сне действительно работает дизайном, но я говорил об уничтожении процесса в бесперебойном сне, который может перестать работать, если системный вызов никогда не просыпается. –  jlliagre 11.01.2011, 23:39
  • 4
    man 5 nfs:" intr/nointr смонтируйте, что опция удерживается от использования после ядра 2.6.25. Только SIGKILL может прервать незаконченную операцию NFS на этих ядрах, и, если указано, эта опция монтирования проигнорирована для обеспечения назад совместимости с более старыми ядрами". –  Reinstate Monica - M. Schröder 07.08.2012, 23:05
  • 5
    @imz - IvanZakharyaschev Не то, чтобы я знаю о (но я не мог бы знать). С sshfs, как последнее прибежище, можно уничтожить sshfs процесс (и аналогично с любой другой файловой системой FUSE: Вы всегда можете размонтирование силы этот путь). –  Gilles 'SO- stop being evil' 28.03.2013, 21:42

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

  • быть зомби. Т.е. процесс, какой родитель не считал статус выхода. Такой процесс не использует ресурсов кроме записи PID. В top это сообщено Z
  • ошибочный бесперебойный сон. Этого не должно происходить, но с комбинацией ошибочного кода ядра и/или ошибочных аппаратных средств, которые это когда-то делает. Единственный метод должен перезагрузить или ожидать. В top это сообщено D.
101
27.01.2020, 19:28
  • 1
    не использует ресурс? –  Luc M 11.01.2011, 06:17
  • 2
    @Luc M: AFAIK не (по крайней мере, на Linux) - за исключением записи в таблице процессов (т.е. PID наряду с такой информацией как владелец, статус выхода и т.д.). Это - просто процесс, которые ожидают подтверждение от partent, который это завершило. огромное спасибо –  Maciej Piechotka 11.01.2011, 07:16
  • 3
    @xenoterracide: В конечном счете да, но если родительский процесс все еще живет (например, это - сессия гнома или что-то, что выполняет подобную роль) у Вас все еще могут быть зомби. Технически это - родительское задание для чистки, но если зомби является осиротевшим init, убирает после него (терминология является причиной, почему классы Unix сделаны при закрытых дверях - любой слышащий о висячих строках, у зомби и уничтожающий в одном предложении могут быть неправильные впечатления). –  Maciej Piechotka 11.01.2011, 12:13
  • 4
    "... только метод должен перезагрузить или ожидать". Ожидать сколько времени? Пять месяцев прошли, и мои зомби все еще там. –  DarenW 14.04.2015, 07:10
  • 5
    @DarenW до родителя подтверждает смерть детей. Для получения дополнительной информации спросите автора программы. –  Maciej Piechotka 16.01.2016, 07:35

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

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

ps aux | awk '$8=="Z" {print $2}'
32
27.01.2020, 19:28
  • 1
    Umm, мне всегда не нравится этот вид "трудных" имен полей с ps. Кто может быть уверен, что обязательное поле всегда будет 8-м со всеми реализациями ps во всех Нельдах? спасибо –  syntaxerror 07.02.2015, 19:15

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

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

26
27.01.2020, 19:28
  • 1
    +1 для упоминания о NFS. Несколько лет отступают, это происходило со мной каждые несколько месяцев - если бы сервер NFS отказал, то клиенты NFS на всех (исправленных) полях RHEL зависли бы. kill -9 обычно не работал, даже после ожидания 60 минут. Единственное решение состояло в том, чтобы перезагрузить. –  Stefan Lasiewski 11.01.2011, 19:02

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

17
27.01.2020, 19:28
  • 1
    я предполагаю много руткитов, вводит себя в ядро для создания вещей более простыми (никакая потребность, предполагающая, какого пользователя имеют и загрузка MBS исправленных программ). Однако это все еще стоит проверить (++ голосование). –  Maciej Piechotka 13.01.2011, 00:12

Уничтожьте на самом деле средства, отправляют сигнал. существует несколько сигналов, которые можно отправить. уничтожьте-9, специальный сигнал.

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

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

уничтожьте-15, отправляет сигналу SIGTERM, который обозначает СИГНАЛ, ОКОНЕЧНЫЙ, другими словами, говорит приложению выходить. Это - дружественный способ сказать приложению, что пора завершить работу. но если приложение не отвечает, уничтожают-9, уничтожит его.

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

11
27.01.2020, 19:28
  • 1
    15 является SIGTERM (дружественное уничтожение), не SIGHUP. SIGHUP для закрываемого терминала управления или потерянный канал передачи –  JoelFan 11.01.2011, 07:53

Процесс init неуязвим для SIGKILL.

Это также верно также для потоков ядра, т.е. "обрабатывает" с PPID, равным 0.

10
27.01.2020, 19:28
  • 1
    Ядра могут также быть неуязвимы для SIGKILL. Это происходит достаточно часто с Btrfs. положительная сторона –  Tobu 28.02.2013, 12:37

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

5
27.01.2020, 19:28
  • 1
    Когда что-то вроде этого происходит, PID на самом деле изменяется. Таким образом, я заметил бы. –  tshepang 12.01.2011, 01:19

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

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

10
27.01.2020, 19:28
  • 1
    у меня были проблемы при уничтожении ls процесс, получающий доступ sshfs смонтируйтесь, когда удаленный сервер будет иметь недостижимый биом. Существует ли решение для FUSE или sshfs, который я мог использовать в будущем для предотвращения таких ситуаций? 2.6.30 ядер –  imz -- Ivan Zakharyaschev 28.03.2013, 16:57
  • 2
    @imz совет от Gilles (для уничтожения sshfs) там - unix.stackexchange.com/a/5648/4319. –  imz -- Ivan Zakharyaschev 30.03.2013, 14:36

Сделанный небольшой сценарий, который помог мне много смотреть!

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

#!/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
6
27.01.2020, 19:28
  • 1
    Вместо того, чтобы просто связаться с ним, может Вы вместо этого отправлять код здесь. –  tshepang 27.03.2013, 22:53
  • 2
    Добавьте немного описания с (или по крайней мере вместо этого) кода... –  vonbrand 27.03.2013, 23:23
  • 3
    Да, но "$name" больше агрегируется..., он уничтожит любой процесс с "$name" в его рабочем пути. Может быть очень полезный whan, у Вас есть эти огромные командные строки, и Вы не знаете, каково имя процесса. –  user36035 01.04.2013, 20:43

Во-первых, проверьте, является ли это Процесс-зомби (который очень возможен):

ps -Al

Вы будете видеть что-то как:

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

(Отметьте "Z" слева),

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

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

Например, при использовании смонтированного устройства или самбы попытайтесь размонтировать ее. Это может выпустить Процесс-зомби.

Примечание: Если ps -Al (или top) показывает "D" вместо "Z", он мог быть связан с удаленным монтированием (как NFS). По моему опыту, перезагрузка является единственным способом пойти туда, но можно проверить другие ответы, которые касаются того случая более подробно.

11
27.01.2020, 19:28
  • 1
    Отправка SIGCHLD к родительскому процессу может заставить родителя распознавать, что процесс умер. Это должно работать даже когда PPID = 1. Это обычно отправляется ядром, но может быть отправлено с в родителя через уничтожение также (уничтожьте-17 на Linux, начните работу, страницы справочника другой *отклоняют). Это использование уничтожения на самом деле "не уничтожит" родителя, а скорее (ре) сообщает этому, что ребенок умер и должен быть очищен. Обратите внимание, что sigchld должен быть отправлен в родителя зомби, не зомби самого. –  Stephanie 21.01.2014, 13:21

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

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

strace -p <PID>

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

gdb <path to binary> <PID>

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

3
20.08.2021, 13:38

Tuve un tipo de este problema. Este fue un programa que había iniciado con stracee interrumpido con Ctrl+ C. Terminó en un estadoT(rastreado o detenido ). No sé cómo sucedió exactamente, pero no se podía matar con SIGKILL.

Para resumir, logré matarlo congdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit
4
20.08.2021, 13:38

Основываясь на подсказке из ответа Жиля, у меня был процесс, помеченный «Z» вверху(<defunct>в ps ), который использовал системные ресурсы, у него даже был открыт порт, который ПРОСЛУШИВАЛ, и вы могли подключиться к этому порту. Это было после выполнения kill -9. Его родителем был "1" (, т.е. init), поэтому теоретически он должен просто повториться и исчезнуть. Но нет, он торчал, хотя и не бегал, и «не умирал»

.

Так что в моем случае это был зомби, но все еще потребляющий ресурсы... FWIW.

И он не мог быть убит никаким числом kill -9х

И его родителем был init, но он не собирался (очищаться ). т.е. initбыл ребенок-зомби.

И перезагрузка не понадобилась для решения проблемы. Хотя перезагрузка «сработала бы» вокруг проблемы / ускорила выключение. Просто не грациозно, что еще было возможно.

И это был порт LISTEN, принадлежащий процессу-зомби (и несколько других портов, таких как CLOSE _Состояние WAIT, подключенное между локальным хостом и локальным хостом ). И он еще даже принимал соединения. Даже будучи зомби. Я предполагаю, что еще не удосужились очистить порты, поэтому входящие соединения по-прежнему добавлялись в журнал ожидания порта прослушивания tcp, хотя у них не было шансов быть принятыми.

Многие из вышеперечисленных заявлены как "невозможные" в различных местах в интерсетях.

Оказалось, что у меня был внутренний поток внутри него, который выполнял «системный вызов» (ioctl в этом экземпляре ), на возврат которого уходило несколько часов (это было ожидаемое поведение ). По-видимому, система не может завершить процесс «полностью», пока он не вернется из вызова ioctl, думаю, он входит в землю ядра. Через несколько часов он вернулся, все прояснилось, все розетки были автоматически закрыты и т. д., как и ожидалось. Это какое-то томительное время в камере смертников! Ядро терпеливо ждало, чтобы убить его.

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

Также проверьте dmesg, чтобы узнать, была ли паника ядра (, то есть ошибка ядра ).

-1
20.08.2021, 13:38

Теги

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