[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Правильные" демоны - не демоны?



On Sun, 13 Sep 2009 17:53:04 +0400
Artem Chuprina <ran@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

Attachment: pgpc3j6vagSwZ.pgp
Description: PGP signature


Reply to: