Re: "Правильные" демоны - не демоны?
Alexander Galanin -> debian-russian@lists.debian.org @ Sun, 13 Sep 2009 19:01:50 +0400:
>> AG> Более того, я считаю необходимым условием то, что когда init мне
>> AG> бодро сообщил о завершении своей работы запуском xdm, система
>> AG> должна быть готова к эксплуатации.
>>
>> Не говоря уже о том, что sysvinit никак тебе этой гарантии не дает. (И
>> слава богу - у меня система поднимет xdm несмотря на то, что vmware не
>> поднялась - а не поднялась она потому, что модули надо под новое ядро
>> пересобрать, ибо если б не апгрейд ядра, я б вообще не перегружался - и
>> что мне, в консоли корячиться со сборкой этих модулей? - ах да,
>> getty-то она с твоими предпочтениями тоже не запустила бы...)
AG> sysvinit даёт мне гарантию, что он честно попытается запустить все
AG> скрипты
В это верю...
AG> и внятно обругается в консоль, если что пошло не так.
... а в это - нет. Ты посмотри на любой процесс загрузки с ошибками. И
попробуй потом найти там ошибку, ага... Выкинутую наивным скриптом
в stderr, а не в сислог или хотя бы dmesg.
AG> Потому уточняю формулировку требования: честно попытаться всё запустить
AG> перед приглашением войти в систему, чтобы не создалось ситуации, когда я
AG> уже залогинился, а nfs всё ещё не смонтирован.
То есть если у тебя тот конец лежит, то твоя машина не должна тебе дать
возможности залогиниться. Тогда событийная модель к твоим услугам.
Именно событийная, а не sysvinit.
А вот если ради удовлетворения твоих закидонов оно так станет вести себя
_у меня_ - вот тут-то я и начну искать способ пришибить тебя и сделать
по-человечески...
>> AG> Ты готов своей репутацией отвечать за то, что все инит-скрипты
>> AG> написаны и будут писаться без race?
>>
>> AG> Даже если добавить в полиси строчку "инит-скрипт должен быть
>> AG> написан так, чтобы позволять параллельное выполнение со другими
>> AG> инит-скриптами", это не улучшит ситуацию. Система должна быть
>> AG> устойчивой к ошибкам by design.
>>
>> Так эта проблема и при последовательном запуске точно так же в
>> полный рост. Хинт: если демон уже форкнулся, отсетсидился и еще раз
>> форкнулся, и даже, может быть, pid-файл записал, это еще не значит,
>> что он готов к работе и его услугами можно пользоваться.
AG> То, что конкретный демон и конкретный его инит-скрипт завершились
AG> до того, как им стало возможно пользоваться --- проблема
AG> исключительно этого демона. И к init-у это мало относится.
Твоими бы устами да медку хряпнуть. Таковы 9 демонов из 10.
AG> У pppd, к примеру, есть на такой случай замечательная опция
AG> updetach. Или вот ещё ifupdown, который не завершается, пока не
AG> получит адрес по dhcp.
... в то время как мне сеть для логина нафиг не нужна, а нужна как раз
после - ибо нифига тут DHCP не дают, и чтобы ее получить, надо ручками
адрес прописать. Ну и на кой?
AG> И не стоит забывать, что мантайнеры не всегда добросовестные и не
AG> всегда компетентные, чтобы отследить и проверить все
AG> пререквизиты. В качестве примера того уровня, на котором находится
AG> продумывание инит-скриптов, могу указать то, что для thttpd и
AG> ejabberd на команду stop демон вообще не убивался (не знаю, как
AG> сейчас обстоят дела).
Ты не выкручивайся. Ты покажи, чем тут последовательная загрузка лучше
параллельной. В параллельной ты, если обнаружил, что мейнтейнер забыл
пререквизит, сам его вписываешь, и тебе ура. А в последовательной?
Танцы с бубном вокруг числа после буковки S? Или от того, что загрузка
последовательная, мейнтейнер сразу станет на порядок ответственнее и
будет эти танцы танцевать сам? Так ты ж сам контрпримеры приводишь...
>> Только при последовательном запуске об этом регулярно забывают - и
>> потому при нем race у нас в полный рост. А когда в голове держат
>> параллельный, пререквизиты все-таки проверяют.
AG> Не многовато ли пререквизитов проверять придётся? Пример: в скрипте
AG> для запуска экзима надо будет проверять, смонтировался ли
AG> /var/spool, который может быть на nfs-е, поднялись ли сетевые
AG> интерфейсы из конфига и т.д.
Ты туда хоть заглядывал, в этот инит-скрипт экзима?
# Required-Start: $remote_fs $syslog $named $network $time
# Required-Stop: $remote_fs $syslog $named $network
Он мало того, что проверяет все, что ты сказал - он еще и проверяет то,
что ты забыл...
>> >> Получается довольно прозрачная с точки зрения концепции идея:
>> >> есть события, генерируемые ядром, есть события типа "сервис X
>> >> стартовал", есть зависимости от событий в стартовой
>> >> последовательности. И всё.
>>
>> AG> Если заходить со стороны отладки, то получается
>> AG> трудноотлаживаемая конструкция. Потому что отследить по
>> AG> линейным логам, на каком из пяти параллельно запущенных
>> AG> процессов инициализация "грохнулась", весьма и весьма
>> AG> проблематично.
>>
>> Use grep, Luke!
AG> Ну нагрепаю я, что загрузка у меня встаёт, когда одновременно
AG> запущены скрипты для xdm, console-setup и fbset. И что? Ребутнуться
AG> ещё десяток раз, исключая их по одному, да так проблему и не
AG> поймать, потому что всё было из-за того, что в первый раз в фоне
AG> драйвер для сканера неправильно подгрузился. Или любое другое
AG> абсурдное стечение обстоятельств, которое никому в голову не пришло
AG> продумать.
Ты эта... Не мешай одно с другим. Если у тебя драйвер сканера
неправильно подгрузился, то у тебя загрузка не встанет. У тебя, может
быть, не загрузится saned. И даже если он не загрузится настолько
неудачно, что зависнет, не реагируя на сигналы - или реагируя, но на
машинке без клавиатуры и монитора - это в sysvinit у тебя будут
проблемы, а в параллельной модели они откуда возьмутся?
--
kernel bug (англ.) - ядрёна вошь
Reply to: