SIGKILL (Работает не всегда)

[Ivanhoe]

В теории сигнал 9 (KILL) должен вызывать немедленное безусловное уничтожение получившего его процесса. Беда в том, что он работает не всегда.

Только что у меня завис kopete. Я попробовал убить его с помощью опции "Убить" окна в IceWM. Окно закрылось, но процесс остался, что явно показал ps -e. Тогда я сделал сначала killall kopete, но бесполезно. Затем
# kill -9 <PID>, и все равно, kopete продолжать висеть в списке, что показывали и top и ps. Многократное повторение kill ни к чему не привело. В итоге спасла перезагрузка.

Но возникает тогда вопрос - как вообще может быть так, чтобы процесс игнорировал SIGKILL? Поясните, плиз.

[Uncle_Theodore]

* Zombie processes cannot be killed since they are already dead and waiting for their parent processes to reap them.

* Processes that are in the blocked state will not die until they wake up again.

* An uninterruptibly sleeping process may not terminate (and free its resources) even when sent SIGKILL. This is one of the few cases in which a UNIX system may have to be rebooted to solve a temporary software problem.

http://en.wikipedia.org/wiki/SIGKILL

[anonymous.ru]

Ситуация такая:
Ядро переводит процесс в непрерываемый режим в момент когда от имени процесса генерируется запрос к устройству на котором находится файловая система и до получения ответа от этого устройства. Обычно периуд между запросом и ответом устройства невелик (особенно с точки зрения человека), НО если устройство получило запрос и не ответило (например вообще отвалилось), то процесс так и остается висеть в этом режиме в ожидании устройства.
Вопрос: где находились файлы с которыми работал kopete?

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

примерно так

[Ivanhoe]

Спасибо, понятно. Значит только ребут?