Я в небольшом шоке.
Итак:

вырезка из топа:



предыдущую процедуру повторял раз 10.

sudo kill эффекта тоже не дает.

Процессу хоть бы хны. Завис и закрываться не хочет.

Дочерних процессов нет, вроде бы:
pstree:


Есть идеи, как это прибить без перезагрузки?

это бывает возможно, когда программа:
1. игнорирует signal 9
2. спит ( suspended )
3. waiting for I/O

в некоторых случаях смерть наступает очень много времени после посыла сигнала.
в некоторых программа потихоньку переходит в состояние ZOMBIE.

короче - RTFM

по ману вообще-то программа его игнорировать не может...

В зомби или defunct программа не перешла за полчаса.

В общем, кроме перезагрузки, ничего не помогло.

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

как прибить можно было тот процесс без перезагрузки. Нельзя так нельзя.

JackYF, 
такое может быть, когда процесс находится в состоянии 
TASK_UNINTERRUPTIBLE
например ожидание на операции I/O (у меня такое было, когда я пытался читать с неисправного CD-ROM)

kill просто устанавливает бит в маске сигналов нужного процесса и ничего более (поэтому возвращаемое значение = 0 (echo $?))
на пришедший сигнал должен реагировать сам процесс (которому этот сигнал пришел), вызвав do_signal()
проверка этим процессом флага TIF_SIGPENDING в thread_info происходит в некоторых заранее определенных точках кода (например при возвращении из системного вызова)
но так как у нас процесс "застрял" в цикле ожидания события (см. выше), то поток выполнения не попадает ни в одну из этих точек и do_signal() не может быть вызван, тем самым нет реакции на посылку сигнала
имхо, выхода тут нет никакого
разве что писать модуль ядра и попытаться вручную завершить процесс (но тут есть опасность того, что в wait_some_event() были захвачены блокировки или другие средства синхронизации)
что для этого надо
1. Пишем модуль-убийцу   (в качестве интерфейса взаимодействия USER <-> KERNEL используем, например, /proc)
2. В модуле реализуем процедуру "убивания", которая:
    а) Находит нужный процесс (по pid-у)
    б) Находит адрес области памяти по которому сохраняется контекст процесса при его переключении

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


Это сообщение отредактировал(а) MAKCim - 24.8.2007, 11:22

MAKCim, развернуто, спасибо.

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

Я что-то забыл/упустил?

а причина по которой оно должно это сделать?
нету причины...по крайней мере с точки зрения ядра
процесс ресурсы CPU практически не использует, только проверяет возникновение события и сам отдает управление другому процессу
да, есть необработанные сигналы, но процесс должен их сам обработать
почему?
вот банальный пример
мы ставим обработчик на сигнал SIGINT
обработчик находится в адресном пространстве процесса (< 0xC0000000)
процесс перешел в режим ядра и там "завис"
мы посылаем ему kill, kill - обычный системный вызов, выполняющийся в контексте специально созданного для этого процесса
семантика обработки сигнала предусматривает проверку, был ли установлен процессом его обработчик
но т. к kill работает в другом процессе и доступ к обработчику он не имеет (адресные пространства пользователя различны), поэтому он просто устанавливает флаг в битовой маске сигналов нужного процесса, что дескать пришел сигнал и нужно его обработать, когда сможешь
все-таки по умолчанию Linux - это не Real-Time система, поэтому 100%-ой реакции на событие ожидать не приходится

про средства синхронизации оно ничего не знает
в thread_info процесса есть поле preempt_count (счетчик захваченных блокировок)
оно увеличивается на 1 при захвате любой блокировки (спин-блокировки, семафора и т. д)...и все
т. е ядро не в курсе адресов самих блокировок и их типов, поэтому ничего сделать не может

хм, кое-что прояснилось...


э? а кто же тогда отвечает за реализацию всех этих самых средств сихнронизации?

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

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

Добавлено через 4 минуты и 8 секунд
по поводу книжек
нет ничего лучше исходников  ...ну или этой книги

Или Таненбаума  Та книга всё-таки предполагает, что читатель знаком с устройством ОС.

powerfox, 
имхо, она написана очень неплохо и главное не слишком сложно
поэтому, думаю, пойдет   

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