как убить два процесса?

0

0

имею:

root@silverblood (/home/andrey)# ps ax | grep mount            
17838 ?        D      0:00 umount /media/cdrom/
17988 ?        D      0:00 /bin/mount -t auto -s -o gid=plugdev,user /dev/cdrom /media/cdrom
18473 pts/2    R+     0:00 grep mount
root@silverblood (/home/andrey)# ps ax | grep mount
17838 ?        D      0:00 umount /media/cdrom/
17988 ?        D      0:00 /bin/mount -t auto -s -o gid=plugdev,user /dev/cdrom /media/cdrom
root@silverblood (/home/andrey)# kill -9 17838                 
root@silverblood (/home/andrey)# ps ax | grep mount
17838 ?        D      0:00 umount /media/cdrom/
17988 ?        D      0:00 /bin/mount -t auto -s -o gid=plugdev,user /dev/cdrom /media/cdrom
root@silverblood (/home/andrey)# kill -9 17988                 
root@silverblood (/home/andrey)# ps ax | grep mount
17838 ?        D      0:00 umount /media/cdrom/
17988 ?        D      0:00 /bin/mount -t auto -s -o gid=plugdev,user /dev/cdrom /media/cdrom
root@silverblood (/home/andrey)# kill -9 17838 &  kill -9 17988
[1] 18493
[1]   Done                    kill -9 17838
root@silverblood (/home/andrey)# ps ax | grep mount            
17838 ?        D      0:00 umount /media/cdrom/
17988 ?        D      0:00 /bin/mount -t auto -s -o gid=plugdev,user /dev/cdrom /media/cdrom
root@silverblood (/home/andrey)# 

не могу убить ни один из двух процессов
что делать?

Ссылка

←	spurious 8259A interrupt: IRQ15

Компиляция новым GCC нового GCC

→

в dmesg чисто

generatorglukoff ★★
(28.11.07 22:29:31 MSK) автор топика

статус процесса "D" видишь? Перезагрузка только поможет.

anonymous
(28.11.07 22:45:16 MSK)

Ссылка

Процесс в D-состоянии нельзя убить, это одна из кривейших фич лялиха.

Попробуй насильно извлечь диск - скрепкой или что там у тебя под рукой.

tailgunner ★★★★★
(28.11.07 22:45:44 MSK)

Ответ на: комментарий от tailgunner 28.11.07 22:45:44 MSK

Это проблема не только линукса (тебе кстати к логопеду, быдло), но и соляриса, hp-ux'a и пр.

anonymous
(28.11.07 22:48:58 MSK)

Ответ на: комментарий от anonymous 28.11.07 22:48:58 MSK

> Это проблема не только линукса

На остальные мне класть с прибором, а ляликс это не извиняет.

> тебе кстати к логопеду, быдло

ПНХ

tailgunner ★★★★★
(28.11.07 23:04:29 MSK)

Ссылка

Ответ на: комментарий от generatorglukoff 28.11.07 22:29:31 MSK

я разобрался:

1. у меня отходят контакты питания привода (hdc)
2. это наглухо останавливает один из винтов (hda) - музыка глохнет (через минут 5 - видимо кэш), а еще на нем своп торчит
3. но системный винт (hdb) продолжает работать
4. система продолжает функционировать повидимому на кэше в оперативной памяти. когда он заканчивается - она полностью виснет
5. баг воспроизводится - проверенно

теперь вопрос такой: что делать в таких ситуациях (кроме ребута)? я пытался сделать hdparm -U /dev/hdc - не помогло, сначала проглатывало, а потом зависло.

PS <offtop>а если попытаться добавить комментарий от топикстартера - не добавляет</offtop>

generatorglukoff ★★
(28.11.07 23:16:30 MSK) автор топика

Ответ на: комментарий от generatorglukoff 28.11.07 23:16:30 MSK

> 1. у меня отходят контакты питания привода (hdc)

> ...

> что делать в таких ситуациях

Ставить контакты на место :)

tailgunner ★★★★★
(28.11.07 23:24:31 MSK)

Ответ на: комментарий от tailgunner 28.11.07 23:24:31 MSK

>> что делать в таких ситуациях

>Ставить контакты на место :)

я имел ввиду програмно =)

можно ли систему при таком раскладе вернуть к жизни?

generatorglukoff ★★
(28.11.07 23:31:38 MSK) автор топика

Ответ на: комментарий от generatorglukoff 28.11.07 23:31:38 MSK

> можно ли систему при таком раскладе вернуть к жизни?

Программно - нет. Только провода выдергивать. D-сотояние - это обычно финиш, процесс бессмертен, даже ребут может не пройти.

Вроде работа по решению вопроса ведется, но результатов пока нет.

tailgunner ★★★★★
(28.11.07 23:38:29 MSK)

Ответ на: комментарий от tailgunner 28.11.07 23:38:29 MSK

>Вроде работа по решению вопроса ведется, но результатов пока нет.

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

generatorglukoff ★★
(28.11.07 23:47:15 MSK) автор топика

Ответ на: комментарий от generatorglukoff 28.11.07 23:47:15 MSK

>>Вроде работа по решению вопроса ведется, но результатов пока нет.
и не будет, т.к. это никому не нужно

>А жаль. Видимо стоит попробовать присоединится к разработке...
ЛОЛ, ты там негенерируешь глюков. Иди паяй контакты.

P.S. 2 "generatorglukoff & tailgunner" вы просто два пионЭра-клоуна.
Спасибо, повеселили.

anonymous
(29.11.07 07:25:13 MSK)

Ответ на: комментарий от anonymous 29.11.07 07:25:13 MSK

>>Вроде работа по решению вопроса ведется, но результатов пока нет.

>и не будет, т.к. это никому не нужно

Отучаемся говорить за всех.

> 2 "generatorglukoff & tailgunner" вы просто два пионЭра-клоуна.

Ну меня-то - ладно, а генератора за что пионером обозвал? У человека возник вопрос, он спросил.

> Спасибо, повеселили.

Смех продлевает жизнь. Живи долго, анонимный брат.

tailgunner ★★★★★
(29.11.07 10:03:45 MSK)

Ссылка

Ответ на: комментарий от generatorglukoff 28.11.07 23:31:38 MSK

> я имел ввиду програмно =)

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

> можно ли систему при таком раскладе вернуть к жизни?

Да, ресетом на морде системного блока.

~~Lumi~~ ★★★★★
(29.11.07 11:17:42 MSK)

Ответ на: комментарий от Lumi 29.11.07 11:17:42 MSK

>> я имел ввиду програмно =)

> Бороться надо с причиной, а не следствием. Так что исправляй железячную проблему и не парь людям мозг.

Безусловно нужно исправлять железячную проблему, но было бы весьма неплохо, если бы ОС могла сама разрулить подобную проблему (например, отключить неисправный привод). Это, ИМХО, называется надежностью.

generatorglukoff ★★
(29.11.07 16:24:30 MSK) автор топика

Ответ на: комментарий от generatorglukoff 29.11.07 16:24:30 MSK

Ага. ты сними с атлона во время работы радиатор, и подумай о том, что было бы неплохо решить эту проблему программно.

Хочешь такой надёжности, покупай серверное железо, корзины горячей замены и пихай все разделы в рейд.

~~Lumi~~ ★★★★★
(29.11.07 17:57:35 MSK)

Ссылка

Ответ на: комментарий от tailgunner 28.11.07 22:45:44 MSK

> лялиха

Крайне не советую больше употреблять - вредно для кармы.

Deleted
(29.11.07 19:09:29 MSK)

Ответ на: комментарий от Deleted 29.11.07 19:09:29 MSK

> не советую больше употреблять - вредно для кармы.

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

tailgunner ★★★★★
(29.11.07 21:03:49 MSK)

Ответ на: комментарий от tailgunner 29.11.07 21:03:49 MSK

Хорошая работа с хреновым железом не гарантируется нигде

Deleted
(29.11.07 21:20:45 MSK)

Ответ на: комментарий от Deleted 29.11.07 21:20:45 MSK

> Хорошая работа с хреновым железом не гарантируется нигде

Речь не о "хорошей работе", а о том, что здесь аффтары не оставили человеку возможности исправить ситуацию. А всё из-за того, что какой-то суперхацкер влепил wait_event/wait_for_completion вместо wait_event_interruptible/wait_completion_interruptible, или не позаботился о тайм-ауте. Хреновое железо - факт жизни, и драйверы должны вести себя разумно, когда встречают его.

tailgunner ★★★★★
(29.11.07 22:00:34 MSK)

Ответ на: комментарий от tailgunner 29.11.07 22:00:34 MSK

+1. Особенно напрягает при чтении с плохих CD/DVD. При этом ядро начинает сыпать сообщения, что оно не может прочитать такой-то сектор, а программа пытающаяся прочитать файл с CD зависает в состоянии D. Через определённое время правда процесс прекращяется, и программе возвращяеться ошибка чтения, но иногда этот промежуток может быть довольно большой.

platerx ★
(29.11.07 22:53:36 MSK)

Ответ на: комментарий от generatorglukoff 28.11.07 23:16:30 MSK

hda и hdc висят на одном шлейфе?

mky ★★★★★
(30.11.07 00:10:08 MSK)

Ответ на: комментарий от platerx 29.11.07 22:53:36 MSK

> +1. Особенно напрягает при чтении с плохих CD/DVD. При этом ядро начинает сыпать сообщения, что оно не может прочитать такой-то сектор, а программа пытающаяся прочитать файл с CD зависает в состоянии D. Через определённое время правда процесс прекращяется, и программе возвращяеться ошибка чтения, но иногда этот промежуток может быть довольно большой.

Ага. В виндах помнится просто тихо мирно процесс чтения прерывался насмерть и сразу.

В результате мои попытки посмотреть любимый фильм с мааленькой царапиной разбивались о непонимание ОС.

umount -l спасет отца русской демократии.

gena2x ★★★
(30.11.07 12:03:52 MSK)

Ссылка

Ответ на: комментарий от mky 30.11.07 00:10:08 MSK

>hda и hdc висят на одном шлейфе?

нет конечно!

hda + hdb - primary ide
hdc + hdd - secondary ide

как во всех норм компьютерах

generatorglukoff ★★
(30.11.07 13:21:44 MSK) автор топика

Ссылка

Ответ на: комментарий от mky 30.11.07 00:10:08 MSK

> hda и hdc висят на одном шлейфе?

они не могут на одном шлейфе висеть.

Deleted
(30.11.07 17:51:35 MSK)

Ответ на: комментарий от Deleted 30.11.07 17:51:35 MSK

>они не могут на одном шлейфе висеть.

может он устройства переименовал? Кто его знает, с таким псевдонимом то :)

Вопрос то я задал не просто так, а в связи со следующей фразой: "отходят контакты питания привода (hdc) это наглухо останавливает один из винтов (hda)".

И если hda и hdb висят на одном шлейфе, то вобще непонятно, почеу hdb работат, когда hda перестал. По идее, ядро должно делать reset контроллера...

mky ★★★★★
(01.12.07 17:01:33 MSK)

Ссылка

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

←	spurious 8259A interrupt: IRQ15

General

Компиляция новым GCC нового GCC

→

Похожие темы