On Sun, 13 Sep 2009 17:53:04 +0400 Artem Chuprina <r...@ran.pp.ru> wrote:
> Alexander Galanin -> debian-russian@lists.debian.org @ Sun, 13 Sep 2009
> 16:00:12 +0400:
>
> AG> Более того, я считаю необходимым условием то, что когда init мне
> AG> бодро сообщил о завершении своей работы запуском xdm, система
> AG> должна быть готова к эксплуатации.
>
> Не говоря уже о том, что sysvinit никак тебе этой гарантии не дает. (И
> слава богу - у меня система поднимет xdm несмотря на то, что vmware не
> поднялась - а не поднялась она потому, что модули надо под новое ядро
> пересобрать, ибо если б не апгрейд ядра, я б вообще не перегружался - и
> что мне, в консоли корячиться со сборкой этих модулей? - ах да,
> getty-то она с твоими предпочтениями тоже не запустила бы...)
sysvinit даёт мне гарантию, что он честно попытается запустить все
скрипты и внятно обругается в консоль, если что пошло не так. Ещё б при
возникновении ошибок перед стартом xdm выдавал "press anykey" в консоль
--- было б вообще шикарно.
Потому уточняю формулировку требования: честно попытаться всё запустить
перед приглашением войти в систему, чтобы не создалось ситуации, когда я
уже залогинился, а nfs всё ещё не смонтирован.
> AG> У ноутбука есть кнопка suspend, нажимая которую ты дёргаешь не
> AG> /etc/rc?.d/*, а /etc/{suspend,resume}.d/*.
>
> Если б оно еще и работало... А то у моего, скажем, с некоторой
> регулярностью бывает бессонница...
Соболезную, у самого КПК в 1% случаев не просыпается. Но это ни в коем
случае не контраргумент.
> AG> Ты готов своей репутацией отвечать за то, что все инит-скрипты
> AG> написаны и будут писаться без race?
>
> AG> Даже если добавить в полиси строчку "инит-скрипт должен быть
> AG> написан так, чтобы позволять параллельное выполнение со другими
> AG> инит-скриптами", это не улучшит ситуацию. Система должна быть
> AG> устойчивой к ошибкам by design.
>
> Так эта проблема и при последовательном запуске точно так же в полный
> рост. Хинт: если демон уже форкнулся, отсетсидился и еще раз форкнулся,
> и даже, может быть, pid-файл записал, это еще не значит, что он готов к
> работе и его услугами можно пользоваться.
То, что конкретный демон и конкретный его инит-скрипт завершились до
того, как им стало возможно пользоваться --- проблема исключительно
этого демона. И к init-у это мало относится.
У pppd, к примеру, есть на такой случай замечательная опция updetach.
Или вот ещё ifupdown, который не завершается, пока не получит адрес по
dhcp.
И не стоит забывать, что мантайнеры не всегда добросовестные и не всегда
компетентные, чтобы отследить и проверить все пререквизиты. В качестве
примера того уровня, на котором находится продумывание инит-скриптов,
могу указать то, что для thttpd и ejabberd на команду stop демон вообще
не убивался (не знаю, как сейчас обстоят дела).
> Только при последовательном запуске об этом регулярно забывают - и
> потому при нем race у нас в полный рост. А когда в голове держат
> параллельный, пререквизиты все-таки проверяют.
Не многовато ли пререквизитов проверять придётся? Пример: в скрипте для
запуска экзима надо будет проверять, смонтировался ли /var/spool,
который может быть на nfs-е, поднялись ли сетевые интерфейсы из конфига
и т.д.
> >> Получается довольно прозрачная с точки зрения концепции идея: есть
> >> события, генерируемые ядром, есть события типа "сервис X стартовал",
> >> есть зависимости от событий в стартовой последовательности. И всё.
>
> AG> Если заходить со стороны отладки, то получается трудноотлаживаемая
> AG> конструкция. Потому что отследить по линейным логам, на каком из
> AG> пяти параллельно запущенных процессов инициализация "грохнулась",
> AG> весьма и весьма проблематично.
>
> Use grep, Luke!
Ну нагрепаю я, что загрузка у меня встаёт, когда одновременно запущены
скрипты для xdm, console-setup и fbset. И что? Ребутнуться ещё десяток
раз, исключая их по одному, да так проблему и не поймать, потому что всё
было из-за того, что в первый раз в фоне драйвер для сканера неправильно
подгрузился. Или любое другое абсурдное стечение обстоятельств, которое
никому в голову не пришло продумать.
--
Alexander Galanin
pgpQ251ulyXvG.pgp
Description: PGP signature
