Linux не убьет процесс

Обновлено: 05.05.2024

Когда приложение для Linux перестает отвечать на запросы и аварийно завершает работу, как его остановить? Попробуйте один из этих приемов, чтобы принудительно закрыть программу в Linux.

Программное обеспечение Linux достаточно надежно, чтобы работать без проблем, но иногда даже самые лучшие приложения могут зависать. Вместо того, чтобы ждать их сбоя, вы можете убить эти не отвечающие программы. На самом деле существует так много способов убить Linux-программы, что вам может показаться, что вы избалованы выбором!

Если у вас возникли проблемы с приложением в Linux, вот как завершить программу в Linux.

1. Завершите программу Linux, нажав «X»

Возможно, вы уже пробовали уйти и приготовить горячий напиток. Если вы вернулись к своему компьютеру и обнаружили, что приложение все еще зависает, у него было достаточно времени для восстановления. Не отвечающее приложение обычно имеет неактивные кнопки или параметры, которые не работают. Также может быть невозможно перемещать окно приложения по экрану.

Итак, какое решение?

Просто нажмите кнопку X в верхнем углу (слева или справа, в зависимости от вашей операционной системы Linux). Это должно остановить программу. Вы можете увидеть диалоговое окно с предложением подождать или принудительно завершить работу сейчас.

Если все пойдет по плану, некоторые дистрибутивы предложат вам отправить отчет об ошибке.

2. Как убить программу в Linux с помощью системного монитора

Следующий вариант — открыть утилиту системного монитора операционной системы Linux.

Чтобы найти это в Ubuntu:

Ваш дистрибутив, несомненно, будет отличаться, но системный монитор отображает список запущенных процессов на вкладке «Процессы».

Чтобы принудительно завершить процесс Linux, просто выберите его и щелкните правой кнопкой мыши. Затем у вас есть три варианта, которые вы должны попробовать в следующем порядке:

  • Стоп: процесс приостанавливается, и вы можете продолжить его позже. В большинстве случаев это не сработает.
  • Завершение: правильный способ закрыть процесс, это безопасно завершит приложение, удалив временные файлы по пути.
  • Убить: это крайний вариант, и его следует использовать только в случае сбоя завершения процесса.

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

3. Принудительное завершение процессов приложений Linux с помощью «xkill»

Еще один вариант, который вы можете использовать, — это xkill.

Это инструмент принудительного уничтожения, предустановленный в Ubuntu, но при необходимости вы можете установить его через Терминал в других дистрибутивах. При вызове xkill позволит вам закрыть любой процесс рабочего стола. Установите его с помощью следующей команды:

После этого запустите xkill, просто набрав

Указатель мыши примет вид креста (или черепа). Нажмите левой кнопкой мыши на проблемное приложение, чтобы закрыть его.

4. Принудительно закройте приложения Linux с помощью команды kill

Не можете закрыть приложение, которое не отвечает, с помощью настольного инструмента? Решением может быть инструмент, который принудительно закрывает приложения Linux в командной строке.

Доступно несколько параметров командной строки, которые помогут вам закрыть приложение. Более того, их можно использовать либо на своем компьютере, либо подключившись через SSH с другого устройства.

Здесь можно использовать команду kill Linux, но сначала требуется идентификатор процесса. Вы можете найти это, запустив команду, запрашивающую у приложения идентификатор процесса:

В результате будет отображаться идентификатор процесса. Затем это можно использовать для остановки процесса Linux следующим образом:

Обратите внимание, что если ваша команда kill app для Linux не удалась, вам может потребоваться добавить команду с помощью sudo.

5. Используйте команды принудительного уничтожения Linux «pgrep» и «pkill»

Что делать, если вы не знаете или не можете найти идентификатор процесса? Здесь на помощь приходит команда pkill. Вместо идентификатора процесса просто используйте pkill вместе с именем процесса:

Кроме того, вы можете использовать команду pgrep, чтобы найти идентификатор процесса:

…и после этого используйте pkill с идентификатором процесса.

Как и в случае с командой kill, это должно закрыть процесс Linux примерно через 5 секунд.

6. Принудительное уничтожение экземпляров Linux с помощью killall

Не повезло с kill или pkill? Пришло время использовать ядерный вариант: killall.

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

Все, что вам нужно, это имя процесса и команда killall (возможно, с помощью sudo, если этого требуют ваши настройки).

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

7. Принудительное завершение процесса в Linux с помощью сочетания клавиш

Хотите сэкономить время, закрывая не отвечающее программное обеспечение? Лучший вариант — создать сочетание клавиш. Это даст вам немедленную возможность закрыть приложение, но для этого требуется xkill. Вот как это работает в Ubuntu:

  1. Откройте «Настройки» > «Сочетания клавиш».
  2. Прокрутите вниз и нажмите +, чтобы создать новый ярлык

Чтобы использовать сочетание клавиш, когда приложение зависает, просто используйте сочетание клавиш. Указатель мыши примет форму X, и вы сможете щелкнуть в любом месте приложения, которое хотите закрыть.

Регулярно принудительно закрывать приложения Linux? Обновите свое оборудование

Регулярно ли возникают проблемы с приложениями, которые не отвечают? Возможно, вам было бы полезно внести некоторые изменения в аппаратное обеспечение вашего компьютера с Linux.

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

Теперь вы знаете, как завершить программу в Linux

Итак, в следующий раз, когда приложение или утилита Linux зависнет и перестанет отвечать, все, что вам нужно сделать, это применить одно из следующих решений:

  1. Нажмите X в углу.
  2. Использовать системный монитор
  3. Используйте приложение xkill
  4. Используйте команду kill
  5. Закройте приложения Linux с помощью pkill
  6. Используйте killall для закрытия программного обеспечения.
  7. Создайте сочетание клавиш для автоматического закрытия приложения в Linux

Если вы обнаружите, что регулярно завершаете работу приложений Linux, которые не отвечают, почему бы не подумать о переходе на более легкую операционную систему Linux?

Я пытаюсь улучшить свои навыки работы с командной строкой и столкнулся с проблемой, когда не могу завершить процесс. Я набираю kill 2200, где 2200 — это мой PID, и процесс не уничтожается. Через несколько минут ожидания все еще в топе и ps aux. Я даже пытался ввести его с помощью sudo - безрезультатно.

Есть идеи, почему это так?

Я обнаружил странную зависимость, когда fg обновляет список процессов:



Что это был за процесс? Вы проверяли, может быть, процесс прекратил свое существование? В этом случае вам нужно будет убить родительский процесс.

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

Если вы приостановите процесс с помощью CTRL-z, он будет блокировать большинство сигналов, пока он приостановлен (т. е. пока вы не нажмете fg или bg для процесса)

8 ответов 8

Процессы могут игнорировать некоторые сигналы. Если вы отправите SIGKILL, он не сможет его проигнорировать (и не перехватит для очистки). Попробуйте:

Узнайте больше, прочитав страницу руководства:

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

А иногда нет родительского процесса, и в этом случае вы просто облажались. Единственный способ удалить такой процесс — перезагрузить машину.

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

Если kill вызывается без каких-либо параметров, он отправляет сигнал номер 15 ( SIGTERM ). Этот сигнал может быть проигнорирован процессом. Этот сигнал уведомляет процесс о необходимости очистить свои вещи, а затем завершить его правильно. Хороший способ.

Вы также можете "отправить" сигнал номер 9 ( SIGKILL ), который не может быть проигнорирован процессом. Процесс его даже не узнает, потому что ядро ​​завершает процесс, а не сам процесс. Это плохой путь.

Говорят убить -9

Всегда работает. Это заблуждение. Бывают ситуации, когда даже kill -9 не убивает процесс. Например, когда процесс находится в состоянии D (непрерываемый сон). Процесс входит в это состояние каждый раз, когда он ожидает ввода-вывода (обычно не очень долго). Таким образом, если процесс ожидает ввода-вывода (например, на неисправном жестком диске) и он не запрограммирован должным образом (с тайм-аутом), то вы просто не можете убить этот процесс. Не важно, что вы делаете. Вы просто можете попытаться сделать файл доступным, чтобы процесс продолжался.

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

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

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

14 ответов 14

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

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

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

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

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

Если процесс остается в непрерывном спящем режиме в течение длительного времени, вы можете получить информацию о том, что он делает, подключив к нему отладчик, запустив диагностический инструмент, такой как strace или dtrace (или аналогичные инструменты, в зависимости от вашей версии Unix). ) или с другими диагностическими механизмами, такими как /proc/PID/syscall в Linux. См. Невозможно убить процесс wget с помощью kill -9 для получения дополнительной информации о том, как исследовать процесс в непрерывном спящем режиме.

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

В запущенной нами установке Concourse мы недавно заметили, что определенный тип рабочей нагрузки (Kubernetes в Docker в Concourse) вызывал сильное раздражение: никогда бы этого не сделал!

Вот кое-что из того, что я узнал, изучая, как Linux обрабатывает сигналы, когда дело доходит до завершения процесса, и чем это отличается от случая, когда процесс зависает.

подает верный сигнал об уничтожении

Если вы когда-нибудь хотели принудительно завершить процесс, вы наверняка использовали для этого классический kill -s SIGKILL $pid, верно? Давайте создадим пример, в котором вам было бы интересно это сделать:

В этом случае, поскольку мы блокируем доставку сигналов процессу, мы можем гарантировать, что простой SIGINT от ctrl+c не уничтожит его - такой сигнал останется в ожидании, таким образом, действие по умолчанию (завершение ) никогда не произойдет.

Если только мы не отправим SIGKILL.

Глядя на генерацию сигнала ( /usr/bin/kill ), мы видим, что он просто запрашивает ядро ​​(через kill(2) ):

Но что происходит внутри?

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

убит под колпаком

Linux посылает сигналы процессу всякий раз, когда приходит время переключиться из режима ядра в пользовательский режим для данного процесса (т. е. когда он собирается получить квант времени или данный системный вызов вот-вот вернется).< /p>

Мы можем увидеть, насколько это верно, запустив следующий пример:

Если между отправкой этого сигнала мы поместим kprobe на do_exit , мы сможем вернуть стек вызовов обратно к тому, что убило сон — обработке сигнала:

Это уже говорит нам о некоторых вещах:

сразу после того, как ядро ​​готово выполнить пользовательский код, оно проверяет сигналы

прежде чем продолжить выполнение процесса, он завершается (с помощью do_exit ).

Итак, во-первых, когда ядро ​​собирается получить некоторое время для запуска процесса, оно проверяет, есть ли какие-либо ожидающие сигналы, которые следует проверить.

Каждый найденный сигнал обрабатывается.

Проверяя, что с ним делать, в случае с нашим SIGKILL, он обнаруживает, что должен умереть, и так и поступает.

убить под капотом

Точно так же, как мы делали это для убиваемого процесса, мы также можем выяснить, как выглядит путь кода ядра для kill(1) , бинарного файла, использующего системный вызов kill(2) для перевода SIGKILL в спящий режим .

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

После того, как все проверки пройдены, мы можем перейти к самой интересной части: настоящей отправке.

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

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

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

И, естественно, поскольку ядро ​​всегда хочет, чтобы сигналы SIGKILL перехватывались, оно жестко указывает, что SIGKILL должен возвращать значение true для Want_signal:

завершение зависшего процесса

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

  • он должен быть запланирован к запуску.

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

Обратите внимание, что это отличается от случая, когда сигнал SIGSTOP отправляется процессу, когда процесс просто переводится в состояние, которое все еще можно прервать.

Читайте также: