On Fri, May 09, 2003 at 03:06:42AM +0500, ASA wrote:

> DS> У меня были только общие идеи. Для каждого стартового скрипта должно быть
> DS> описание зависимостей -- после запуска какого скрипта можно запускать этот
> DS> скрипт. Зависимость должна быть двух типов -- обязательная, и
> DS> необязательная. Обязательная -- значит что если не поднимается тот сервис,
> DS> от которого зависит нужный нам, то он даже не будет пытаться подниматься.
> Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)

:)

> DS> Необязательные -- только обеспечивают соблюдение очерёдности.
> А  это  хорошая  идея.  Относительно.  Но очередность уже есть в
> SysV.

В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
сервер должен запускать после антивирусного сервиса, если таковой
имеется".

Соответственно последовательность работы загрузчика следующая -- берётся
список поднимаемый сервисов, строится дерево зависимостей, дальше
запускаем скрипты инициализации для N сервисов, из тех, которые можно
инициализировать сразу. После завершения каждого из скриптов смотрим что
следующее можно инициализировать.

 > DS> Думаю доказывать прирост в скорости загрузки не надо.
 > Надо.   С   теми  скриптами,  которые  в  основном  налегают  на
 > недисковые  ресурсы (сеть, обработка конфигов и т.п.) - понятно.
 > А  если скрипт в основном завязан на диск, то его надо запускать
 > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
 > нетривиальная  задача  развязки  обязательных  и  необязательных
 > зависимостей.

А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
сформулировать что необходимо его сервису для работы.

Насчёт завязки на диск -- что это, например? Сервер БД на что больше
завязан? IMHO сервер БД можно запускать как только смонтированы все
разделы и подняты интерфейсы (если он не локальный).

Для многопроцессорных систем польза от многопоточного запуска, IMHO,
очевидна. 

Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
-jN), которая увеличивает скорость компиляции даже на однопроцессорных
машинах.

 > DS> Вопрос только в
 > DS> одном -- настолько ли оно надо, чтобы тратить на это силы?
 > Имхо нет. Предлагаю промежуточную копромиссную схему, которая не
 > требует больших усилий.
 > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
 > поле  типа  как это сделано для chkconfig. В этом поле указываем
 > класс скрипта - дисковый или нет.

Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
 
 > Затем    rc-скрипт   (тот,   который   обеспечивает   выполнение
 > SysV-инициализации)  последовательно выполняет скрипты не просто
 > отсортировав SXX по порядку (типа `echo S*|sort`), а разбивая их
 > на  группы  по  приоритету  (S00  -  в одну кучу, S01 в другую и
 > т.п.).  Внутри  этой  группы  rc смотрит на поле класса скрипта,
 > находит  и  запускает  в  два  независимых "потока" "дисковые" и
 > "недисковые" скрипты.
 > Получаем,  во-первых,  полную  совместимость  с уже существующим
 > софтом,    завязанным    на   SysV,   а   во-вторых,   требуемое
 > распараллеливание скриптов.
 > Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
 > зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
 > такого  способа  задания  зависимостей  не  представляет  вообще
 > никакого труда.

Собственно этим и можно в результате сделать точно ту схему, о которой я
писал выше. Только тогда придётся шерстить все скрипты.
 
-- 
С уважением, Денис

http://freesource.info