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

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



Alexander Galanin -> debian-russian@lists.debian.org  @ Sun, 13 Sep 2009 16:00:12 +0400:

 AG> Более того, я считаю необходимым условием то, что когда init мне
 AG> бодро сообщил о завершении своей работы запуском xdm, система
 AG> должна быть готова к эксплуатации.

Ну а я так не считаю.  Подеремся?

Не говоря уже о том, что sysvinit никак тебе этой гарантии не дает.  (И
слава богу - у меня система поднимет xdm несмотря на то, что vmware не
поднялась - а не поднялась она потому, что модули надо под новое ядро
пересобрать, ибо если б не апгрейд ядра, я б вообще не перегружался - и
что мне, в консоли корячиться со сборкой этих модулей?  - ах да,
getty-то она с твоими предпочтениями тоже не запустила бы...)

При событийной модели ты хотя бы можешь прописать зависимости - и
система будет тебе запускать xdm тогда и только тогда, когда она подняла
все сервисы.  (Оно, конечно, ты наплачешься, когда у тебя какой-нибудь
сервис не поднимется - но ССЗБ, кто ж тебя просил такие глупости
делать?)

 >> Но зачем? Если это мой ноутбук, который мне надо загрузить быстро?

 AG> У ноутбука есть кнопка suspend, нажимая которую ты дёргаешь не
 AG> /etc/rc?.d/*, а /etc/{suspend,resume}.d/*.

Если б оно еще и работало...  А то у моего, скажем, с некоторой
регулярностью бывает бессонница...

 >> Зачем запускать что-то последовательно и висеть то на процессоре, то на
 >> вводе-выводе, если у нас 2, 4, 8 ядер? Давайте распараллелим процесс
 >> загрузки, будем запускать сервисы и всякие инициализационные скрипты as
 >> early as possible.
 >> ...
 >> Ну и надо минимально напрячь мейтернеров пакетов, предоставляющих
 >> инит-скрипты.

 AG> Ты готов своей репутацией отвечать за то, что все инит-скрипты
 AG> написаны и будут писаться без race?

 AG> Даже если добавить в полиси строчку "инит-скрипт должен быть
 AG> написан так, чтобы позволять параллельное выполнение со другими
 AG> инит-скриптами", это не улучшит ситуацию. Система должна быть
 AG> устойчивой к ошибкам by design.

Так эта проблема и при последовательном запуске точно так же в полный
рост.  Хинт: если демон уже форкнулся, отсетсидился и еще раз форкнулся,
и даже, может быть, pid-файл записал, это еще не значит, что он готов к
работе и его услугами можно пользоваться.

Только при последовательном запуске об этом регулярно забывают - и
потому при нем race у нас в полный рост.  А когда в голове держат
параллельный, пререквизиты все-таки проверяют.

А система у нас многозадачная, извините, by design.  Кому не нравится -
есть MS-DOS и MacOS, которая не X.

 >> Получается довольно прозрачная с точки зрения концепции идея: есть
 >> события, генерируемые ядром, есть события типа "сервис X стартовал",
 >> есть зависимости от событий в стартовой последовательности. И всё.

 AG> Если заходить со стороны отладки, то получается трудноотлаживаемая
 AG> конструкция. Потому что отследить по линейным логам, на каком из
 AG> пяти параллельно запущенных процессов инициализация "грохнулась",
 AG> весьма и весьма проблематично.

Use grep, Luke!

-- 
Все гениальное просто.
Но со вкусом.
	Кнышев.


Reply to: