Как убить процесс? kill -9 не работает.

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

лопатой

>процесс кому принадлежит?
Юзерский. Убивал и из под юзера и через sudo.

>лопатой
$ sudo apt-get install лопата
E: Couldn't find package лопата
А точнее)

я такое один раз видел. Причины остались невыяснеными.

sensor что говорят. Так ничего у вас не греется часом. Или оный процесс не висит случайно в попытке read 3 на недоступный ресурс?

> Как убить процесс? Гарантировано? Чтоб он умер?

Никак. Есть ситуации, при которых процессы не умирают. Обычно это связано с неправильным функционированием железа в сочетании с кривыми драйверами. Распознается по нахождению процесса в состоянии D.

Покажи дерево процессов, относящихся к твоему живчику.

ps axf, например...

Нет не греется. Процесс - это простая программа - призваная для того чтобы упасть (затерается стек случайными данными). 
И в программе 100 потоков. 
В большенстве случаев программа падает, но иногда стаёт неубиваемой.

Пример:
void thread()
{
  int a[1];
  int * b = a;
  while(true){
    LOG("%p", (void)b);
    *b++ = rand();
  }
}

и 100 pthread_create в цикле

> Никак. 

Странно. Что вообще никак? На десктопе - это одно дело. 
Но на сервере неверно сконфигурированый постфикс (или какаято другая почтовая система) просто вешала нам сервер - отжирая 100% проца. 
Тогда тоже не могли убить процесс и пришлось ребутить сервер 
(на котором было много пользователей).
 
>Есть ситуации, при которых процессы не умирают. Обычно это связано с неправильным
>функционированием железа в сочетании с кривыми драйверами. >Распознается по нахождению процесса в состоянии D.

Есть буковка Д:

ghisguth@x61s:~$ ps aux |  egrep "(USER|test)"

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
ghisguth 12911  5.1 68.7 21782180 1400096 pts/7 Dl+ 00:15   0:16 ./test -asegfault2 --int1=500

>Покажи дерево процессов, относящихся к твоему живчику. 
>ps axf, например...

12538 ?        S      0:00  \_ /bin/sh -c xterm   
12539 ?        S      0:03  |   \_ xterm
12540 pts/7    Ss     0:00  |       \_ bash
12911 pts/7    Rl+    0:15  |           \_ ./test -asegfault2 --int1=500
12

>> Никак.

> Странно. Что вообще никак?

С гарантией - никак. В 99.99% случаев kill -9 в конце концов доходит до процесса, но иногда... Есть такое состояние процесса - TASK_UNITERRUPTIBLE, оно часто используется в драйверах при ожидании завершения В/В, и в нем процесс не реагирует на сигналы. Халтурно сделанные драйверы не взводят при этом тайм-аут, и потенциально процесс может остаться вечным и неубиваемым. Такое бывает еще и при внезапно отвалившихся ФС (сетевых или локальных - без разницы). Однако то, что у тебя процесс "чистый" (без В/В), и при этом не убивается - странно. В логах что-нибудь есть?

> ghisguth 12911 5.1 68.7 21782180 1400096 pts/7 Dl+ 00:15 0:16 ./test -asegfault2 --int1=500

Попробуй убивать его из-под рута.

Какая версия ядра? Какой дистр?

>С гарантией - никак. В 99.99% случаев kill -9 в конце концов доходит до процесса, но иногда...
Теперь вроди как понятно почему нет реакции на kill (D == Uninterruptible sleep == TASK_UNITERRUPTIBLE). Но почему он стал таким - не совсем ячно. Единственная задача программы упасть попортив стек в потоках.

>Попробуй убивать его из-под рута.
Пробовал - ноль реакции. По идее чтоб остановить такой процесс - надо в самом ядре изменить статус задачи. Может можно это сделать через /proc/ интерфейс?

>Какая версия ядра?
Linux x61s 2.6.24-17-generic #1 SMP Thu May 1 13:57:17 UTC 2008 x86_64 GNU/Linux

>Какой дистр?
Ubuntu 8.04

> Но почему он стал таким - не совсем ячно.

Аха. Что в логах?

> Может можно это сделать через /proc/ интерфейс?

Нет.

> Ubuntu 8.04

Я бы попробовал ванильное 2.6.24.7 или 2.6.25.4

А нельзя ли запустить снова через strace и посмотреть, что именно за ввод-вывод он в это время делает?

И я правильно понял, что время он кушает именно в ядре? (/usr/bin/top покажет как %sy)

Если оно в ядре - ему может быть пофиг на киллы. Возможно либо кривое железо, либо криво собранное ядро, либо просто бага в ядре.

У меня какое-то смутное подозрение, что процесс, который специально затирает свою память, может не реагировать на kill'ы, примерно как циклоп в выколотым глазом может не оценить искусства Марселя Марсо...

> процесс [...] может не реагировать на kill'ы

kill -9 неотменяемый и неперехватываемый. И не реагировать на kill он может только если ждет чего-то в ядерной функции.

> И не реагировать на kill он может только...

я правильно понимаю, это ядро его должно прибить, а не он сам «сдохнуть», да? т.е. сигнал, он через ядро передается, да?

> kill -9 неотменяемый и неперехватываемый.

А получаемый? :)

> И не реагировать на kill он может только если ждет чего-то в ядерной функции.

После того, как стек переписан рэндомными байтами, поведение процесса становится непредсказуемым. Что значит -- реагирует-не реагирует, если у него вместо реагировалки написаны цифры числа пи после миллионного знака?

Вопрос решен. Всё оказалось достаточно просто;)

Проблема заключалась в следующем:

1. при записи рандомных значений в стек - падение происходит не с одинаковыми интервалами времени. Тоесть программа работает до сегфолта затирая память иногда секунды 3-5, а иногда 20-30.
2. Чем раньше случился сегфолт - тем меньше стартовало потоков и меньше памяти было затерто.
3. генерация коры проходит быстро если сегфолт произошел в течении 1-10 секунд. Если программа проработала достаточно долго - то генерация коры может длится до 5 минут (у меня стоит большое ограничение на размер коры и пока ядро запишет всю инфу которую хочет - например всю память которую подпортила програма - проходит много времени).
4. Соответственно ядро производит дамп коры и в этот момент его прервать нельзя.

Всем спасибо за помощь.

> После того, как стек переписан рэндомными байтами

Передачей сигналов ведает ЯДРО.

Сигнал kill приводит к жестокому и стремительному "выносу" процесса из таблицы процессов. С освобождением всех его ресурсов - в том числе страниц стека, файловых дескрипторов, mmap и прочим. И ядро при выносе задачи не смотрит на то что у нее там написано в юзерспейсе.

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

P.S.: и раздачей сигналf родительскому процессу о том, что дочерний процесс был прибит, также ведает ядро, если что.

> если у него вместо реагировалки написаны цифры

Еще раз, man signal: { The signals SIGKILL and SIGSTOP cannot be caught or ignored}. Эти сигналы обрабатываются целиком ядром, на основании его внутренних структур, и до процесса не доводятся. И что там процесс попытался навесить на эти сигналы, никого не колебет.

> это ядро его должно прибить, а не он сам «сдохнуть», да?

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

Я так делаю,
сначала вот:
ps aux | grep -i "примерное_название_головного_исполн_файла"
например mplayer
Потом точнее:
sudo killall mplayer

> Да. SIGTERM передается процессу, чтобы он умер сам (император приказал совершить сеппуку). SIGKILL отрабатывается ядром (император послал наемного убийцу).

Зачётная аналогия :)))

sudo killall

спасибо, я так и думал.

> Зачётная аналогия

Моя стараться очень сильно :-)

> Соответственно ядро производит дамп коры и в этот момент его прервать нельзя.

coredump-бомба :-)

#include <string.h>

int main() {
    while (1) {
        if (!fork()) {
            memset( malloc( 2048*2048 ), 2048*2048, 0 );
            memset( NULL, 1024, 127 );
        }
    }
}

Кстати, а как лимиты на coredump регулируются? Точнее, где про это почитать?

>Вопрос решен. Всё оказалось достаточно просто;)

В следующий раз попробуй родительские процессы погрохать

>Кстати, а как лимиты на coredump регулируются? Точнее, где про это почитать?

в дебиане /etc/security/limits.conf и
ulimit -c <ЗНАЧЕНИЕ>

>Точнее, где про это почитать?
+ http://linux.die.net/man/5/core )))

> В следующий раз попробуй родительские процессы погрохать

В первом посте писал - что не помогло. Как помогли разобратся - если процесс назодится в состоянии UNINTERUPTABLE - то ни что, кроме ядра, не в силах остановить процесс.

> ядро производит дамп коры и в этот момент его прервать нельзя.

Это _очень_ странно. Запись коры - это обычная работа с ФС, она должна быть прерываемой. Я даже припоминаю, что прерывал ее обычным Ctrl-C.

"Темна вода во облацех" (c)

Интересно как это?
Обработчик сигнала SIGSEGV пишет себе потихоньку корку, процесс сидит в D, а соответственно никакие Ctrl-C к нему не придут.

Народ, хватит тупить. Если процесс заблокирован на I/O, то он не может жрать процессор. Он вообще в sleep находится и никому не мешает. А если он жрет процессор, то он должен по SIGKILL быть мгновенно прибит.

> Интересно как это?

Да ХЗ. Могу ошибаться.

> Обработчик сигнала SIGSEGV пишет себе потихоньку корку, процесс сидит в D

Если он занимается В/В, его состояние должно меняться. И кто его ставит в D? Кусок кода можешь показать?

> Если процесс заблокирован на I/O, то он не может жрать процессор. Он вообще в sleep находится и никому не мешает. А если он жрет процессор, то он должен по SIGKILL быть мгновенно прибит.

Второе утверждение неверно.

>Это _очень_ странно. Запись коры - это обычная работа с ФС, она должна быть прерываемой. Я даже припоминаю, что прерывал ее обычным Ctrl-C.

Работа с ФС может быть прервана только между "атомарными" операциями с ФС. Когда вывоз находится в kernelspace, но нельзя. Хотя уже довольно долгое время в ядре включена фича? которая позволяет прерывать операции и когда они в kernelspace.

>Второе утверждение неверно.

Ну, я имею в виду жрет процессор в userspace. Так как если в kernelspace, то процессор жрет уже ядро. А обычно это происзодит при беспрерывных вызовах kernel функций. И сигнал дойдет после обработки очерезного вызова. То есть очень быстро.

>Хотя уже довольно долгое время в ядре включена фича? которая позволяет прерывать операции и когда они в kernelspace.

Не помнишь ли, как фича называется?

>И сигнал дойдет после обработки очерезного вызова. То есть очень быстро.

У топикстартера не все так просто...