On Tue, May 13, 2003 at 09:38:14PM +0500, ASA wrote:

 > DS> Приведёшь пример, где это действительно нужно (я про OR)?
 > # requires postgres
 > # requires musql

И как оно себя поведёт, если отвалится постгрес, когда в конфиге у
этого сервиса прописано использовать именно постгрес?

В любом случае сие должно, IMHO, заменяться на более логичное

# requires sqlserver
 
 > >> а сами
 > >> имена не должны больше нигде повторяться (то есть не допускается
 > >> одновременное задание имени mta в двух и более рабочих скриптах,
 > DS> Скажем есть у нас postgres и mysql. Почему бы им обоим не provides
 > DS> sqlserver?
 > Но это будет работать только в том случае если последующие
 > программы юзают СУБД-незаивсимые интерфейсы...
 > А в алгоритм надо внести уточнение: скрипты с requires sqlserver
 > запускается только после того как отработают все скрипты,
 > которые provides sqlserver и хотя бы один из них будет успешным.

Всё проще. С точки зрения алгоритма просто появится некий виртуальный
скрипт sqlserver, который requires всех тех, кто его provides, и который
не требует запуска.
 
 > DS>  > В  "корневых"  S-скриптах  (т.е.  таких,  которые  не зависят от
 > DS>  > других) пишется
 > DS>  > # requires none
 > DS>  > чтобы  запускающему  скрипту  (rc-скрипту)  было понятно, что он
 > DS>  > (S-скрипт) удовлетворяет вышеописанным требованиям.
 > DS> А может вообще без параметров?
 > а как тогда дать управляющему скрипту понять, что он
 > удовлетворяет нашему RFC? ;)

Я имею в виду просто

# requires
 
 > DS>  > Проблемы: переход на другой runlevel, в том числе останов?
 > DS> Каков сейчас алгоритм перехода на другой runlevel? Я не до конца себе его
 > DS> представляю.
 > Опишу текущее поведение SysV при переходе на runlevel X:
 > Последовательнно  перебираются  все скрипты в /etc/rc.d/rcX.d от
 > K00  до  K99,  потом  от  S00  до  S99.  При переборе K-скриптов
 > проверяется,  был  ли  он  запущен,  согласно  записям         в
 > /var/lock/subsys,  если  такой  "отметился",  то он вызывается с
 > параметром  stop,  затем  при  переборе S-скриптов проверяется -
 > если  его  нет в /var/lock/subsys, то он вызывается с параметром
 > start.
 > Этот алгоритм хорошо работает как и при первичном запуске, так и
 > последующей смене уровней.

Угу... В таком случае нам просто надо построить алгоритм обработки K*
скриптов? 
 
 > DS>  > Описание  алгоритма  запуска (в т.ч. лимит на число одновременно
 > DS>  > запущенных скриптов) - Денису.
 > DS> Я, кажется, приводил его в одном из писем. Основная идея в том, что мы
 > ab просил все свести в один файл.

Буду думать как более-менее разумно его сформулировать.
 
> DS> строим дерево очерёдности запуска (не зависимости, а именно очерёдности),
> DS> после чего выбираем все скрипты, которые можно запустить сразу, и создаём
> DS> очередь на исполнения. Из этой очереди скрипты уже и запускаются. После
> DS> завершения скрипта (или попытки его запуска) мы смотрим на наше дерево,
> DS> убираем из него наш скрипт, и модифицируем само дерево в зависимости от
> DS> результата его выполнения и типа связей этого узла с другими (requires или
> DS> after), после чего те скрипты, которые стало возможно запустить,
> DS> отправляем в очередь.
> ОК. Теперь думай как его доработать для смены runlevel'а.

/me пошёл пытаться думать :)

-- 
С уважением, Денис

http://freesource.info