Как убить процесс максимально эффективно? kill -9 pid не убивает.

wikipedia

Будучи посланным процессу, SIGKILL вызывает его немедленное завершение. В отличие от SIGTERM или SIGINT этот сигнал не может быть перехвачен или проигнорирован, а процесс, получивший его не имеет возможности выполнить какие-либо действия перед своим завершением.

Как-то странно. Может чего путаешь?

Никак - вытащи железку.

Если процесс в D-состоянии, его нельзя убить вообще никак. Лялекс - говно, да.

>Лялекс - говно, да.

Венда рулез :)

Ничего не путаю.
А при чем тут железки? Повис вообще vmware-tray намертво.

Я конечно извиняюсь, но что такое D-состояние?
p.s. Гугл не знает что это такое.

> Если процесс в D-состоянии, его нельзя убить вообще никак.

такой процесс вроде как ведро должно само прибить, не?

Не, оно ждёт ответ от хардвере.

uninterruptible sleep

Сейчас глянул - одна из копий висит аж с 29 июня. Не мешает, но загодочно, черт побери.

В убунте называется «непрерываемый»

>> Если процесс в D-состоянии, его нельзя убить вообще никак.

такой процесс вроде как ведро должно само прибить, не?

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

> Не, оно ждёт ответ от хардвере.

Часто, но отнюдь не обязательно.

погуглил тут слегка.. вообще-то, в некоторых случаях, его можно прибить. вот здесь - http://linuxgazette.net/issue83/tag/6.html - пишут:

What I usually do is to kill the parent process, which is usually a bash shell. In many / most cases this allows killing of the errant process. However, you may run into the situation where the driver or a port is hung. In those cases, you may have no choice but to reboot.

>Не, оно ждёт ответ от хардвере.

И если модуль ядра (драйвер) не обеспечивает ПОЛНОЕ управление (хотя это в 99% случаев означает быдлоподелку спеков), то только reboot.

Да, тоже нагуглил по uninterruptible sleep state, пойду в ребут...
Первый раз такое наблюдаю.

Надо железо нормальное юзать (в первую очередь на серваки это относится само собой - проверенное в общем).

Ядро само ОЧЕНЬ адекватно себя ведёт. Убить всех неРМСов :)

> Надо железо нормальное юзать

Тебе ведь сказали - не имеет это отношения к железу. Любой модуль ядра может такое устроить.

к сожалению, чаще родитель - init :(

Нашелся виновник - зажатая кабелем клавиша.
Но причинно-следственная связь совершенно неочевидна.
Почему именно vmware-tray?!

>Тебе ведь сказали - не имеет это отношения к железу. Любой модуль ядра может такое устроить.

Вот у меня усть платы, которые сделаны ВНИИНС, так они через досбокс работают и их не убить...

Расскажи, если есть варианты - буду премного благодарен.

Да тот же бехолдер (на этом компе) - работает твтайм, я запускаю ффмпег - всё - плата в ауте.

> Расскажи, если есть варианты - буду премного благодарен.

Сетевые шары часто вызывают процессы в D-состоянии.

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

Посмотрю, только там 2.4 (сервак).

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

> можно все сигналы обрабатывать

Кроме SIGKILL (kill -9) и SIGSTOP (kill -19), эти два не перехватываются и не игнорируются ни при каких условиях :-)

Да, disk sleep - это песня. Самый простой способ его схватить - это писать с помощью wodim содержимое /dev/cdrom на /dev/cdrom. Ничего не поделаешь, это Linux.

Что интересно, я впервые так и схватил бессмертный процесс.

емнип это deadlock зовется?

Нет, deadlock - это взаимная блокировка нескольких процессов при работе с разделяемыми ресурсами.