зависший процесс
Alexandr Lopatin
научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
выпросить алгоритм работы с crash и adb применительно к этой ситуации.
Alexandr
Eugene Karpachov
> научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
> прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
Никак. Он спит в ядре, и просил его не будить. Это не ошибка, а дизайн
такой.
--
jk
Valentin Davydov
> Date: Mon, 12 Aug 2002 04:14:02 +0000 (UTC)
>
>> научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
>> прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
>
>Никак. Он спит в ядре, и просил его не будить. Это не ошибка, а дизайн
>такой.
Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
залип.
Вал. Дав.
Eugene Karpachov
> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
> залип.
Я имею в виду дизайн ядра, в котором присутствует такой вызов. Раз вызов
присутствует, значит, кто-то его придумал и ввёл в ядро - вот это и есть
дизайн.
--
jk
Alex Tomas
VD> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это
VD> процесс залип.
возможно это совсем не ошибка дизайна. почитайте чего-нить что-ли
--
пора
Vasily Korytov
>> From: Eugene Karpachov <j...@steel.orel.ru>
>> Date: Mon, 12 Aug 2002 04:14:02 +0000 (UTC)
>>
>>> научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
>>> прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
>>
>> Никак. Он спит в ядре, и просил его не будить. Это не ошибка, а дизайн
>> такой.
VD> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
VD> залип.
Вовсе не обязательно.
,----[ FreeBSD Handbook, Chapter 3 Unix Basics ]
| 3.6 Daemons, Signals, and Killing Processes
| [...]
| Notes
|
| [1] Not quite true--there are a few things that can not be interrupted.
| For example, if the process is trying to read from a file that is on
| another computer on the network, and the other computer has gone away
| for some reason (been turned off, or the network has a fault), then the
| process is said to be ``uninterruptible''. Eventually the process will
| time out, typically after two minutes. As soon as this time out occurs
| the process will be killed.
`----
--
With respect, Vasily Korytov
PGP key fingerprint: A4FE 4665 A720 687F 4ECC 1474 7C16 C498 BAAB C999
Valentin Davydov
> Date: Mon, 12 Aug 2002 17:12:45 +0000 (UTC)
>
>> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
>> залип.
>
>Я имею в виду дизайн ядра, в котором присутствует такой вызов.
Какой такой вызов?
Вал. Дав.
Eugene Karpachov
>>Я имею в виду дизайн ядра, в котором присутствует такой вызов.
>
> Какой такой вызов?
uninterruptible_sleep или как он там где называется.
--
jk
Valentin Davydov
> Date: Tue, 13 Aug 2002 07:32:32 +0000 (UTC)
> >>
> >>> научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
> >>> прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
> >>
> >> Никак. Он спит в ядре, и просил его не будить. Это не ошибка, а дизайн
> >> такой.
>
> VD> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
> VD> залип.
>
>Вовсе не обязательно.
>
>,----[ FreeBSD Handbook, Chapter 3 Unix Basics ]
>| 3.6 Daemons, Signals, and Killing Processes
>| [...]
>| Notes
>|
>| [1] Not quite true--there are a few things that can not be interrupted.
>| For example, if the process is trying to read from a file that is on
>| another computer on the network, and the other computer has gone away
>| for some reason (been turned off, or the network has a fault), then the
>| process is said to be ``uninterruptible''. Eventually the process will
>| time out, typically after two minutes. As soon as this time out occurs
>| the process will be killed.
>`----
Типичный пример ошибки дизайна драйвера NFS (к слову сказать, отсутствующей
в драйверах других сетевых файлух вроде самбы). Для исправления, вон, даже
специальный ключик придумали:
man mount_nfs
-i Make the mount interruptible, which implies that file system
calls that are delayed due to an unresponsive server will fail
with EINTR when a termination signal is posted for the process.
Вал. Дав.
Alex Tomas
>> существуют ситуации, в которых гораздо проще (с точки зрения
>> реализации) рассматривать некую последовательность
>> _непрерываемой_,
VD> Вот это и есть design bug. Делать надо так, чтобы надёжно
VD> работало, а не так, как проще программировать в дельфях.
совершенно не согласен. ибо овчинка должна стоить выделки
>> я лично сталкивался с такой ерундой. был выбран именно
>> uniterruptible_sleep, иначе пришлось бы такого наворочать
VD> А зачем вообще был выбран sleep? Сделал бы всё сразу, без
VD> остановки.
точно.. будем все поллить. вернемся к msdos
--
пора
Valentin Nechayev
VD>> Это ошибка дизайна. Обычно того ядерного драйвера, в котором это процесс
VD>> залип.
VK> Вовсе не обязательно.
VK> ,----[ FreeBSD Handbook, Chapter 3 Unix Basics ]
VK> | 3.6 Daemons, Signals, and Killing Processes
VK> | [...]
VK> | Notes
VK> |
VK> | [1] Not quite true--there are a few things that can not be interrupted.
VK> | For example, if the process is trying to read from a file that is on
VK> | another computer on the network, and the other computer has gone away
VK> | for some reason (been turned off, or the network has a fault), then the
VK> | process is said to be ``uninterruptible''. Eventually the process will
VK> | time out, typically after two minutes. As soon as this time out occurs
VK> | the process will be killed.
VK> `----
Непрерываемость дискового и NFS'ного sleep - одна из грубейших ошибок
проектирования unix'ов.
/netch
Valentin Nechayev
AL> научите как прибить процесс, который (ну не вдаваясь в тех подробности) не
AL> прибивается не 9-м не 15 сигналом, это не зомби. Хочется на самом деле
AL> выпросить алгоритм работы с crash и adb применительно к этой ситуации.
Система-то у тебя какая? Неужто Bell UNIX V7?
У каждой из них настолько много специфики в этом вопросе, что без точной версии
(повторяю: _точной_ версии) ничего сказать нельзя.
/netch
Alexandr Lopatin
18 Aug 02 19:52, Valentin Nechayev wrote to me:
AL>> научите как прибить процесс, который (ну не вдаваясь в тех
AL>> подробности) не прибивается не 9-м не 15 сигналом, это не зомби.
AL>> Хочется на самом деле выпросить алгоритм работы с crash и adb
AL>> применительно к этой ситуации.
VN> Система-то у тебя какая? Hеужто Bell UNIX V7?
VN> У каждой из них настолько много специфики в этом вопросе, что без
VN> точной версии (повторяю: _точной_ версии) ничего сказать нельзя.
Solaris 8
Alexandr
Eugene Grosbein
VN>> Hепрерываемость дискового и NFS'ного sleep - одна из грубейших ошибок
VN>> проектирования unix'ов.
VK> Пожалуйста, расскажи, почему ты так считаешь. Для меня это неочевидно.
Потому что из-за этого нельзя строить цепочки NFS-серверов, например.
Потому что из-за этого проблемы одновременного чтения диска
из разных user-level тредов, например. И еще есть примеры.
Eugene
--
"Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
Valentin Nechayev
VN>> Непрерываемость дискового и NFS'ного sleep - одна из грубейших ошибок
VN>> проектирования unix'ов.
VK> Пожалуйста, расскажи, почему ты так считаешь. Для меня это неочевидно.
Тут скорее даже не непрерываемость, а ее причина - идиотское построение
работы с драйверами. Не предусмотрены: 1) асинхронная отработка запроса
(хотя в канонической староюниксовой архитектуре против нее нет никаких
возражений - и IPL'и можно ставить как угодно, и completion вызвать,
и wakeup дернуть, и никто тебе не сделает schedule в самый ответственный
момент, и запускать kernel-only процессы для устойчивой обработки на уровне
softinterrupt никто не мешает); 2) отмена запроса к драйверу. При том,
что все это уже было давно - вспомнить хотя бы RT-11, RSX-11 и иже с ними.
В книге по Инмос есть забавное замечание - мол, архитектурный запрет
переключения процессов, находящихся в системной фазе, - решение действенное,
но слишком грубое (например, не дает жить нормальному realtime). Оно показывает,
что более тонкие решения давно уже существовали и были неплохо известны.
В то же время в первых юниксах - был полный бардак. Сделать ожидание ввода
по времени - нереально. O_NONBLOCK во всех видах - отсутствует, select -
отсутствует, AIO - отсутствует, сигналом можно только срубить процесс и ничего
более (обработчики неустойчивы, какое-то улучшение наступило только когда
BSD и ATT параллельно друг другу начали делать reliable signals - а это не
только sigprocmask и sigaction, а и вообще изменение метода реакции ядра
на сигналы, включая sleep и sysentry). Даже подождать пару минут ввода
с консоли и потом сказать "оп-па, ваше время истекло" было нереально.
Когда вводили неблокирующий режим и прерывание сигналом, его ввели для
тех операций, которые заведомо могли иметь неограниченный по длительности
характер - тот же read с терминала или из пайпа. Но для диска было решено,
что ну его нафиг, bio layer менять - себе дороже, и лучше мы в star trek
поиграем.
А потом пришел NFS. Который и BIO, и в то же время сетевой. А системы
устойчивостью не отличаются - они и сейчас не слишком устойчивы, а тогда -
тем более. А потом все чаще стало оказываться, что надо сохранять жизнь
запущенной системы несмотря на местные сбои, и оказалось, что VFS совершенно
не понимает невозможность работы с диском (позы с panic при записи на
защищенную от записи дискету многие помнят), umount насильный невозможен -
хотя почти вся работа там подставить на все vnode фиктивные VMT и
отцепить буфера запрошенных операций - ан нет, базовая идея что с
диском проблем у нас не бывает и что BIO всегда выполняет свои действия
точно и в срок - проникла всюду. Что и дает нынешнее убогое состояние.
Ты сейчас просто не представляешь себе, каким дерьмом был unix раньше
и как его из этого состояния вытаскивали за уши. В первых sh даже cd был
внешней программой - сейчас кому-то сказать, кто знает про сисколл chdir(),
но не знает истории, даст приступ истерического смеха. Эта команда лезла
в память своего родителя и там меняла текущий каталог. А для этого ей
еще надо было загрузиться с диска (кэша никакого кроме как на 15 блоков
включая суперблоки - не было...)
То, что сейчас видим - результат того, что народ взял то, что было доступно -
эту совершенно непригодную для промышленной работы систему - и начал ее
доводить, потому что это было дешевле, чем писать с нуля или покупать
серьезные системы. А в результате имеем то что имеем - под слоем новой
красивой краски выглядывают слои плохо замазанной ржавчины...
/netch
Vasily Korytov
[...]
Спасибо за исчерпывающее повествование. Больше вопросов нет.