Re: [Comm] Re:

Denis Smirnov
1970-01-01T00:00:02Z

[-- Attachment #1: Type: text/plain, Size: 3590 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]