Причины неубиваемости процесса по kill -9. Zombie, D.

state D

Баг ядра.

Плюсую баг в ведре. У самого такое неоднократно было.

Uninterruptible sleep, zombie, PID 0.

А zombie может держать какие-либо ресурсы (кроме памяти), дескрипторы, открытые устройства и т.п.?

А почему вообще возможно наличие zombie при ещё живом init?

А zombie может держать какие-либо ресурсы (кроме памяти), дескрипторы, открытые устройства и т.п.?

Нет, в том числе и память освобождается.

А почему вообще возможно наличие zombie при ещё живом init?

Init не может его подобрать, потому что зомби уже завершился. Собственно, http://en.wikipedia.org/wiki/Zombie_process

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

Зомби существует до тех пор, пока их не подберет (поинтересуется их судьбой или откажется от них) папашка. Соответственно пока он жив init их не заберет. А вот в случае смерти родителя все дети в сиротский дом init и он уж их захоронит (ибо очень любопытен). Впрочем наблюдал такой напряг init-а, что он сим делом заниматся не смог.

Версию ядра в студию.

state D вам о чем нибудь говорит?

например, если процесс висит в системном вызове, по -9 он не убьется, пока не завершится вызов.

А что будет, если процесс сделал какой-нибудь вызов ioctl на внешнее USB-устройство, а оно ёпнулось и навечно повисло, повесив за собой ioctl. Как сделать так, чтобы такой вызов вернулся?

nfs так постоянно делает. А будет ничего хорошего. Как повезет

Использовать микроядро на жабе/питоне/руби.

А если у меня этим USB-девайсом занимается какой-нибудь модуль ядра, можно модуль ядра насильно выдернуть с освобождением всего занятого?

rmmod -f, не?

ymn

По rmmod -f выдернуть модуль можно, но освобождения ресурсов при этом не происходит. Более того, если этот модуль используется какими-либо устройствами, при следующем обращении к любому из них произойдёт kernel panic.

Короче, способа борьбы с приложением, навечно повисшим в ядре в вызове ioctl или блокируемом read при глюке внешнего USB-девайса нет?

К сожалению, нет.

Можно попытаться выдернуть девайс (или аппаратно, или записав 1 в /sys/bus/<шина>/devices/<девайс>/remove), но тут тоже может что-нибудь упасть (или запись в remove тоже залочится). Лучше перезагрузиться.