[Comm] RFC на модификацию SysV startup

[Comm] RFC на модификацию SysV startup

[ASA]

Hello Alexander, Denis,

  Опишем предложенную модификацию SysV startup, преследующую две
цели:
1) задать зависимости S-скриптов (т.е. расположенных в
/etc/rc.d/init.d и управляемых черех симлинки в /etc/rc.d/rcX.d/)
друг от друга (главная цель на мой взгляд)
2) сэкономить время запуска компьютера за счет параллельного
выполнения нескольких сркиптов (главная цель по мнению
Дениса).

В начало S-скрипта добавляется от одного до нескольких полей
любого трех типов: requires, after и provides.
Поля добавляются тем же способом, как это сделано для chkconfig:
<знак комментария><пробел><имя_поля><пробел><параметр1><пробел><параметр2>...
Отсутствие всех полей (т.е. если ни одное не присутствует)
обрабатывается специально (см. ниже).

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

Пример:
# requires network mta
Скрипт запустится, только если успешно запустились оба network и mta

Пример:
# requires network
# requires mta postgres
Скрипт запустится, если был успешно запущен либо network, либо
оба сервиса mta и postgres.

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

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

Пример:
# after network mta
Скрипт запустится после попыток запуска как и network так и mta

Пример:
# after network
# after mta
Скрипт запустится после любого из network или mta.

Комбинация requires и after:
# requires network
# after mta
Скрипт запустится только после успешного поднятия network и
попытки запуска mta.

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


Поле  provides  встречается  только  один  раз,  и  обеспечивает
альтернативное  имя  скрипта,  которое может быть использовано в
полях  requires  и  after. Полезно для случаев, когда могут быть
разные скрипты, обеспечивающие один и тот же сервис, например, в
системе  могут  быть  установлены либо sendmail, либо exim, либо
postfix. Для всех них в скрипт пишется:

# provides mta

Последующие  скрипты,  котоые  зависят от службы доставки писем,
могут  ссылаться  на  одно  универсальное  название  mta  вместо
перечисления   sendmail,   exim,   postfix   в   каждой  строчке
requires/after по отдельности

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

Само  имя  скрипта  (после  отбрасывания  начального SXX, и, при
необходимости, конечного .*sh) работает как неявный provides.

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

Если  в  S-скрипте  нет  ни одного из всех трех полей (requires,
after,   provides),   то   он   считается   не   удовлетворяющим
вышеприведенным  правилам,  и  rc-скрипт  неявно задает для него
поле  after,  содержащее  все скрипты, имеющие меньший запускной
номер, например, если мы имеем S25blabla без наших полей, то для
него  будет неявно указано, что в after прописаны все скрипты от
S00 до S24.

Проблемы: переход на другой runlevel, в том числе останов?

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


Рекомендуемые поля для скриптов, запускающих сетевые сервисы
# requires netfs
# after named

или

# requires mta
# after named

последовательность запуска основных сетевых сервисов:
network, named, netfs, mta

Я  указываю  на эту тонкость, т.к. первым побуждением мейтернера
будет использовать network, а не netfs.


Еще пример:
в apache пишется:
# after mysql postgres и др. СУБД

Если перебросите в devel@, то просьба в обсуждениях cc: мне и
Денису, т.к. мы не подписаны :)

-- 
Best regards,
 ASA                          mailto:llb@udm.ru

[Comm] Re: [Comm]

[Denis Smirnov]

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

On Mon, May 12, 2003 at 09:29:16AM +0500, ASA wrote:

> 2) сэкономить время запуска компьютера за счет параллельного
> выполнения нескольких сркиптов (главная цель по мнению
> Дениса).

Это не главная цель, это цель, ради достижения которой я вообще и подумал
в первый раз о необходимости сделать подобную систему. Для многих
зависимости скриптов друг от дурга гораздо более полезная фича.

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

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

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

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

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

> Поле  provides  встречается  только  один  раз,  и  обеспечивает
> альтернативное  имя  скрипта,  которое может быть использовано в
> полях  requires  и  after. Полезно для случаев, когда могут быть
> разные скрипты, обеспечивающие один и тот же сервис, например, в
> системе  могут  быть  установлены либо sendmail, либо exim, либо
> postfix. Для всех них в скрипт пишется:
> # provides mta

Это _не_ альтернативное имя. Это именно 'provides'. То есть сервисы,
которые предоставляются этим скриптом. Аналогично тому, как это может быть
в RPM.

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

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

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

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

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

> также  не  допускается  совпадение  имени  какого-либо скрипта и
> содержимого provides).

Лучше разделить пространства имён.

 > Само  имя  скрипта  (после  отбрасывания  начального SXX, и, при
 > необходимости, конечного .*sh) работает как неявный provides.

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

А может вообще без параметров?
 
 > Если  в  S-скрипте  нет  ни одного из всех трех полей (requires,
 > after,   provides),   то   он   считается   не   удовлетворяющим
 > вышеприведенным  правилам,  и  rc-скрипт  неявно задает для него
 > поле  after,  содержащее  все скрипты, имеющие меньший запускной
 > номер, например, если мы имеем S25blabla без наших полей, то для
 > него  будет неявно указано, что в after прописаны все скрипты от
 > S00 до S24.
 > Проблемы: переход на другой runlevel, в том числе останов?

Каков сейчас алгоритм перехода на другой runlevel? Я не до конца себе его
представляю.
 
 > Описание  алгоритма  запуска (в т.ч. лимит на число одновременно
 > запущенных скриптов) - Денису.

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

http://freesource.info

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

Re: [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

Re: [Comm] Re: [Comm]

[Denis Smirnov]

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

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

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

Re[2]: [Comm] Re: [Comm]

[ASA]

Hello Denis,

Wednesday, May 14, 2003, 1:37:39 AM, you wrote:

DS>  > # requires postgres
DS>  > # requires musql

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

Есть сервисы, которые используют _именно_ постгрес. Например,
IServerd, на котором у меня крутится уже больше 250 юзеров.

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

DS> # requires

:)))

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

DS> Угу... В таком случае нам просто надо построить алгоритм обработки K*
DS> скриптов? 

Да.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re: [Comm]

[Denis Smirnov]

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

On Wed, May 14, 2003 at 08:20:23AM +0500, ASA wrote:

 > DS>  > # requires postgres
 > DS>  > # requires musql
 > DS> И как оно себя поведёт, если отвалится постгрес, когда в конфиге у
 > DS> этого сервиса прописано использовать именно постгрес?
 > Есть сервисы, которые используют _именно_ постгрес. Например,
 > IServerd, на котором у меня крутится уже больше 250 юзеров.

Тогда ты пишешь 'requires postgres'.

Ещё одна проблема возникает -- есть зависимости, которые реально зависят
от настроек. Можно, конечно, обрабатывать самый худший случай, а можно что-то
тут придумать.

 > DS>  > Этот алгоритм хорошо работает как и при первичном запуске, так и
 > DS>  > последующей смене уровней.
 > DS> Угу... В таком случае нам просто надо построить алгоритм обработки K*
 > DS> скриптов? 
 > Да.

Грубо говоря -- просто дерево ставим с ног на голову. Направление связей
переворачиваем.
 
-- 
С уважением, Денис

http://freesource.info

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