[Comm] Re: [Comm]

[ASA]

Hello Denis,

Tuesday, May 13, 2003, 6:30:16 PM, you wrote:

>> успешного    запуска   других   скриптов.   Параметры   requires
>> складываются по правилу AND, несколько requires OR'ятся.

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

# requires postgres
# requires musql

>> Поле  after  может  встречаться  (если  вообще  есть)  один  или
>> несколько  раз  и  описывает т.н. мягкую зависимость скрипта, то
>> есть  указывает,  после _просмотра_ или _попытки запуска_ какого
>> скрипта  он  должен  запускаться Параметры after складываются по
>> правилу AND, несколько requires OR'ятся

DS> Может "просмотра" заменить на "попытку поиска"?

Наверно.

>> Если какое-то after-имя не встречается в других скриптах (имя
>> скрипта или поле provides), то он считается не запущенным.

DS> Эту фразу, честно говоря, я при первой прочтении даже не заметил :(

Я сам считаю ее сомнительной :)

DS> Я бы даже разделил пространства имён пакетов и provides (добавив
DS> какой-нибудь символ в начало имён последних). Смысл у них ведь совершенно
DS> разный. Одно дело "мне нужен postfix", а другое дело "мне нужно некое
DS> средство доставки почты".

ОК, согласен.

>> Допускается  задание  нескольких  имен в одном provides, но сама
>> строка  provides должна быть одна (если она вообще есть),

DS> А оно надо, это ограничение? IMHO если можно указывать несколько в одной
DS> строке, то разбор не сильно усложнится от того, что этих строк может быть
DS> больше. А иметь их больше позволит комментировать каждую.

наверно.

>> а сами
>> имена не должны больше нигде повторяться (то есть не допускается
>> одновременное задание имени mta в двух и более рабочих скриптах,

DS> Скажем есть у нас postgres и mysql. Почему бы им обоим не provides
DS> sqlserver?

Но это будет работать только в том случае если последующие
программы юзают СУБД-незаивсимые интерфейсы...

А в алгоритм надо внести уточнение: скрипты с requires sqlserver
запускается только после того как отработают все скрипты,
которые provides sqlserver и хотя бы один из них будет успешным.

DS>  > В  "корневых"  S-скриптах  (т.е.  таких,  которые  не зависят от
DS>  > других) пишется
DS>  > # requires none
DS>  > чтобы  запускающему  скрипту  (rc-скрипту)  было понятно, что он
DS>  > (S-скрипт) удовлетворяет вышеописанным требованиям.

DS> А может вообще без параметров?

а как тогда дать управляющему скрипту понять, что он
удовлетворяет нашему RFC? ;)

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.

Этот алгоритм хорошо работает как и при первичном запуске, так и
последующей смене уровней.

DS>  > Описание  алгоритма  запуска (в т.ч. лимит на число одновременно
DS>  > запущенных скриптов) - Денису.

DS> Я, кажется, приводил его в одном из писем. Основная идея в том, что мы
ab просил все свести в один файл.

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

-- 
Best regards,
 ASA                            mailto:llb на udm.ru