LINUX.ORG.RU
Форум — General  

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


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)# 

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

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

anonymous
()

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

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

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

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

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

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

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

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

ПНХ

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

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

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

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

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

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

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

> ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нет конечно!

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

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

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

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

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

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

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

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