Не убиваются процессы linux

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

Источник

Процесс не убивается по kill -9

Доброго времени суток.

Играюсь с настройкой модуля тюнера, и при этом запускаю tvtime и kdetv. Если модуль неправильно настроен, программы тупо виснут, окна убиваются по xkill, в htop состояние процессов — D, по kill -9 не убиваются. Новые запуски программ — новые неубиваемые процессы, не работающие даже с дефолтными настройками модуля, с которыми программы изначально работали.

Собственно вопрос — что делать/ чем убивать/ на что жаловаться? Тюнер нужно настроить, но проверять его таким образом невозможно.

Re: Процесс не убивается по kill -9

strace. смотреть на чем зависло.

Re: Процесс не убивается по kill -9

>htop состояние процессов — D

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

Re: Процесс не убивается по kill -9

Re: Процесс не убивается по kill -9

>В теории можно выгрузить/загрузить модуль (драйвер) тюнера, если он скомпилен модулем

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

Re: Процесс не убивается по kill -9

> на что жаловаться?

На ошибку в драйвере и/или сбой железа

Re: Процесс не убивается по kill -9

>На ошибку в драйвере и/или сбой железа

И как это делать? Какие данные приводить?

Re^2: Процесс не убивается по kill -9

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

так убить надо иксовые программы? перезапуск иксов не помгает?!

Re: Re^2: Процесс не убивается по kill -9

Re: Процесс не убивается по kill -9

>> На ошибку в драйвере и/или сбой железа

> И как это делать? Какие данные приводить?

Подробно опиши ситуацию — модель устройства, версии ядра и драйвера, опции драйвера, что ты пытаешься делать, какие процессы зависают.

Re: Процесс не убивается по kill -9

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

Re: Процесс не убивается по kill -9

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

Может я во что-то не врубаюсь (не программист), но причём здесь тогда драйвер? Происходит вот что: я точно не знаю, какой драйвер нужен для тюнера, и перебираю похожие. Некоторые не работают, с ними-то и зависает tvtime. ioctl — это функция системного вызова, нет? На ней всё и зависает. tvtime уже не развивается, последняя версия ещё в 2005 году. Та же пляска и с kdetv, которое тоже как уже в полумёртвом состоянии. Так что вряд ли это скоро исправят, если исправят вообще. Отсюда, собственно, вопрос — на что пожаловаться, чтобы средствами _системы_ устранять подобные вещи? Ведь неубиваемые процессы — это уже к ядру, не драйверу?

Re: году.

> Может я во что-то не врубаюсь (не программист), но причём здесь тогда драйвер?

Где-то в драйвере ожидается прерывание от устройства или выставление/обнуление бита, которое никогда не происходит. Ожидание без тайм-аута и с запретом обработки сигнала (то самое D-состояние), в этом и ошибка — должен быть либо тайм-аут, либо разрешенная обработка сигналов.

> Отсюда, собственно, вопрос — на что пожаловаться, чтобы средствами _системы_ устранять подобные вещи?

Ну я уже написал, на что.

Re: году.

>Где-то в драйвере ожидается прерывание от устройства или выставление/обнуление бита, которое никогда не происходит. Ожидание без тайм-аута и с запретом обработки сигнала (то самое D-состояние), в этом и ошибка — должен быть либо тайм-аут, либо разрешенная обработка сигналов.

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

Источник

Не убивается процесс Linux

Во время использования операционной системы Linux возникают ситуации, при которых процессы зависают и вы не можете их завершить. Например, вы хотите закрыть графическую программу или сервис, отправляете сигнал TERM, что в переводе означает завершить, а программа не реагирует на него.

Дело в том, что для того, чтобы программа могла завершится с помощью сигнала TERM, она должна быть в рабочем состоянии. Это сигнал просит программу завершится. Если программа зависла, она может попросту не получить ваш сигнал. Или программа может его обработать но не завершатся, этот сигнал носит рекомендательный характер. Вот возможные причины и варианты решения:

• Недостаточно прав — вы не можете убить процесс, запущенный от имени другого пользователя, используйте sudo;
• Программа зависла — необходимо ей послать сигнал KILL;
• Программа стала зомби — необходимо уничтожить её родительский процесс.
• Программа ждет ответа от драйвера — ждать или перезапустить компьютер.

В любом случае сначала пробуем от имени суперпользователя:

Сначала можно попробовать завершить программу с помощью сигнала KILL, для этого передайте -KILL или -9 в виде опции утилите kill:

Если это не работает, можно попробовать посмотреть родительский процесс программы с помощью утилиты ps:

Источник

не убивается процесс

Уважаемое сообщество, помогите, пожалуйста с такой проблемой. На сервере с freebsd программист запустил скрипт, которые не убивается

Подскажите, пожалуйста, что можно сделать

по kill -9 pid само собой не умирает

Disk-state неубиваем. Тут ничего не поделаешь. Возможно, то к чему обращается скрипт, больше нет в системе (сетевая шара, диск, etc.)

Если критично или глаза мозолит, то к сожалению только перегрузка.

И да, PPID у процесса какой ? Убей родителя 🙂

вот это решето ядро bsd

Surprise! Это во всех POSIX системах так. И, о ужас, даже в Linux.

Про фряху хз, но разве в линуксе только перезагрузка? Ведь недоступные/висящие сетевые ресурсы можно отмонтировать через umount -f или если совсем плохо через umount -lf, после чего все D (uninterruptible sleep) либо убиваются, либо сами отваливаются.

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

а если убить его родителя, посмотрев такового через pstree?

Не поможет. Процесс станет потомком процесса PID 1 (init) и всё.

в linux есть alt+sysrq+i например, из того что сходу вспоминается

alt+sysrq+i = Send the SIGKILL signal to all processes except init

Но! Процесс в состоянии D сигналы то не принимает.

не знаю, у меня любые процессы кроме инита подыхают при этом

Подскажите, пожалуйста, что можно сделать

Даже те, что D? Не верю.

Самый простой вариант потестить был бы поднять NFS сервер, прицепиться к шаре и прибить сервер. Любое обращение к маунтам приведёт к D. (тут нечего ругать NFS — это by design so и не лечится)

Если интересно и не лень — можешь сам проверить.

PS: выйти из D мозжно будет опять подняв NFS сервер

PS: выйти из D мозжно будет опять подняв NFS сервер

Выйти из D можно будет сделав umount -f, про что я выше говорил. А у тебя выходило что перезагрузка — единственный вариант.
«Матчасть» (man umount) спецом NFS упоминает:

-f Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.)

Для NFS и umount, если мне не изменяет склероз, в линуксе отдельный, специальный хак, который работает (иногда) соответсвенно только в линукс. На free он не распространяется.

В общем случае, я имел в виду, что это старый, известный workaround для NFS, если тот подвис — поднять на том же IP донер-сервер, что бы на клиенте выйти из D.

У меня прямо сейчас в моём уютном линуксе пачка процессов зомби висит. В результате предыдущих манипуляций демоны после killall перестали потреблять по полтора ядра с, кажется, d-state, но теперь их не перезапустить. UFS в ядре точно рабочая? А с большими файлами? Или это проблема конкретного ПО?

Аватара кагбэ намикаэ =)

По сабжу: ИМХО, насколько понятно по симптомам, только ребут.

Всем спасибо за помощь. Проблема решилась сама, процесс сам пропал. К счастью, перезагружаться не пришлось

Источник