LINUX.ORG.RU
ФорумTalks

[слёзы] процессы


0

0

вот сидит себе firefox-bin в памяти после установки аддона и попытки перезапуска и не убивается, шлю ему лучи по^W^W разные сигналы по очереди (SIGKILL, SIGHUP и т.п.), а ему хоть бы хны.

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

★★★★★
Ответ на: комментарий от Syncro

Он случаем не пытался прочитать что-то с плохой флешки/кривой ФС или что-то такого? если по SIGKILL долго не убивается, то возможно проблемы в работе драйверов. Из под рута не пробовал убивать? У него приоритет при планировании процессов

anonymous
()

Убить то его еще довольно просто, но виснет постоянно сцуко >< прям так и напрашивается на кор дуо, интересно поможет ли..

stave ★★★★★
()
Ответ на: комментарий от stave

> прям так и напрашивается на кор дуо, интересно поможет ли..

Нет. Проверено на Core 2 Duo 3.3ГГц с 4 ГБ памяти. :(

Relan ★★★★★
()

ну и юзай венду дальше :)

anonymous
()
Ответ на: комментарий от anonymous

>(вантузоид|тролль) лоджик детектед

файрфокс юзер лоджик детектед. посиди с ней на пень 1.4, потом говори..

stave ★★★★★
()
Ответ на: комментарий от Relan

>Нет. Проверено на Core 2 Duo 3.3ГГц с 4 ГБ памяти. :(

Печаль..

stave ★★★★★
()
Ответ на: комментарий от anonymous

ну может дело было в том что виртулабокс хрустел вендовым инсталятором каким-то. Неубиваемый фаерфокс пережить можно, а вот если такой неубиваемый процесс rm -rf / делал ? Я об том что когда шлешь команду kill хочется чтобы процесс исчез без всяких выкрутасов даже если он или обстоятельства какие-то особенные.

Syncro ★★★★★
() автор топика
Ответ на: комментарий от Syncro

>вот если такой неубиваемый процесс rm -rf / делал ?

На это случай reset без вариантов.

record ★★★★★
()

Ничего не поделаешь, это uninterruptible sleep

Nao ★★★★★
()
Ответ на: комментарий от stave

>Убить то его еще довольно просто, но виснет постоянно сцуко

Винда?

>501 15233 0.0 0.0 3420 1176 ? SN Feb03 0:00 /bin/sh /home/remoteuser/firefox/firefox


03го - это аптайм такой. Сбой питалова был.

redgremlin ★★★★★
()
Ответ на: комментарий от anonymous

> Если по -KILL не убивается, значит в системе баг.

"О Боже мой !" (C) "И эти люди запрещают мне ковыряться в носу ?!" (C)

Срочно читать про IO wait и Uninterruptible sleep.

Darkman ★★★
()
Ответ на: комментарий от Darkman

>> Если по -KILL не убивается, значит в системе баг.

> "О Боже мой !" (C) "И эти люди запрещают мне ковыряться в носу ?!" (C)

> Срочно читать про IO wait и Uninterruptible sleep.

И что? Это всё равно баг, только немного другого рода.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> И что? Это всё равно баг, только немного другого рода.

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

Darkman ★★★
()
Ответ на: комментарий от Darkman

>> И что? Это всё равно баг, только немного другого рода.

> Какой-такой баг-шмаг, дарагой ?

Вполне обычный баг. Программа (драйвер или ФС) не учитывает, что устройство может сломаться под ним. Упрощенно говоря, параметр (величина отклика) не проверяется на допустимость.

> Вполне задокументированная фича,

Чепуха. Есть функции ожилания с тайм-аутом, но ими пользоваться сложнее. Но надежный софт вообще писать труднне.

> можно даже сказать особенность дизайна. Увы.

Отчасти да.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Упрощенно говоря, параметр (величина отклика) не проверяется на допустимость.

Кому надо работать с битыми носителями - тот умеет. Тот же readcd. А если каждую программу писать с учётом возможных железячных сбоев... жизни хватит ?

Darkman ★★★
()
Ответ на: комментарий от Darkman

Я так понял, речь идёт о kernel-space программах, а не о userspace. В userspace read просто вернёт ошибку какую-нибудь хитрую и всё. А драйверы можно и с учётом сбоев написать.

Legioner ★★★★★
()
Ответ на: комментарий от Darkman

> А если каждую программу писать с учётом возможных железячных сбоев... жизни хватит ?

Драйверы так и надо писать. А стрелок про них говорил.

gaa ★★
()
Ответ на: комментарий от Darkman

> А если каждую программу писать с учётом возможных железячных сбоев... жизни хватит ?

Это не _настолько_ трудно. Обнаруживать ошибки железа и сообщать о них - это прямая обязанность драйвера. Драйвер (железа или ФС), который виснет при аппаратных ошибках - это говнодрайвер. К сожалению, в Линуксе таких дофига.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> К сожалению, в Линуксе таких дофига.

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

Darkman ★★★
()
Ответ на: комментарий от Darkman

> драйвер и отстрелить можно

Процесс в D-state? Нельзя :) Выгрузить зависший драйвер тоже нельзя (то есть можно в принципе, но это смертельно). Поэтому драйвер надо писать разумно, в состоянии паранойи :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Процесс в D-state? Нельзя :) Выгрузить зависший драйвер тоже нельзя (то есть можно в принципе, но это смертельно).

rmmod -f и процесс выходит из D-state. Но да - это смертельно в подавляющем большинстве случаев.

> Поэтому драйвер надо писать разумно, в состоянии паранойи :)

ППКС

Darkman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.