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 (англ.) - ядрёна вошь -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
