On Fri, Sep 19, 2003 at 07:07:31PM +0400, Andrey Orlov wrote:
> On Friday 19 September 2003 12:30, Denis Ovsienko wrote:
> > Вкратце суть сводится к предложению запускать сервисы параллельно,
> > соблюдая зависимости с помощью make. Кто может сказать, можем ли мы себе
> 
> По-моему скорость загрузки сводится не к порядку запуска, а к тому, что
> есть узкое место - быстродействие процессора. Так что хоть последовательно,
> хоть паралельно, хоть по диагонали - никакой разницы. А в связи с конкуренцией
> за ресурсы и затратами на диспетчеризацию, паралельный запуск может __дольше__
> проработать (видел я ту винду .... быстрее грузится, аха. Только залогинились
> (быстро) и сидим ждем, пока система все сервисы стартанет и начнет на кнопки 
> откликаться), и в этом смысле большую помощь окажет отказ от запуска ненужных
> сервисов (коих, на рабочих станциях, по моим наблюдениям, 70%) и покупка чайника,
> чбы включив машину не сразу кнопки топтать, а вначале чайку заварить.
> 
> А что до использования make..... Мндя. Чгря мне вообще идея inittab нравится больше,
> чем идея SystemV скриптов. Раз уж такие вопросы начинают назревать, то нужно
> закинуть SystemV скрипты / inittab на свалку истории и написать специальный
> утиль для старта и мониторинга сервисов.

Эту тему уже пытались поднимать летом, но что-то из-за недостатка интереса
увяло.

ab?

> Чбы решал не только проблему порядка запуска
> но и:
> 
>  1. Старт / Стоп по зависимостям;
> 
>  2. Отслеживание работоспособности (рестарт при необохдимости или
>  поднятие тревоги);

Как будем проверять работоспособность?

>  3. Старт процесса с правами полльзователя;
> 
>  4. Возможно, любимую нами чрутизацию;

Схема "early chroot" не всегда применима.
Скорее бывает наоборот:
первичная инициализация, droppriv, вторичная инициализация.

Но это уже offtopic.

>  5. Ограничение ресурсов, предоставляемых процессу;

Аналогично.

>  6. "Демонизация" процесса (с переназначение stdout / stderr на syslog, 
>   	отслеживанием пида для стоп/старт и т.д.т.п).

Это имеет смысл, как правило, для не-демонов.
Настоящие демоны могут так fork'аться, что их потом без pid-файла не
найти.

>  7. Поддержка единой конфигурации __старта__ процессов (не самих
> 	процессов);

Что имелось в виду?

> И еще очень многое другое.

Что же?
Интересно знать, что нужно пользователям...

> Я отчасти со стороны, отчасти в той степени
> в которой это задевает мои сервисы (Zope, rPAS, omniNames, etc) наблюдаю
> за переписыванием initscripts и их поддержкой, и хотя с одной стороны я горжусь
> тем, что среди AltLinuxTeam есть люди настолько хорошо знающие шелл, с другой - 
> вся эта затея кажется мне обреченной и ненужной: есть задача для сложного
> и нужного сервиса. Все необходимые алгоритмы, типа топологической сортировки,
> в литературе описаны, изобретать особо ничего не надо.

Задачу все-таки надо поставить, прежде чем решать.
Что именно нам не хватает в нынешней схеме?
Что не устраивает?
(У меня есть варианты ответов, но я их пока предлагать не буду).
Все-таки надо сперва хорошо подумать, а уже потом кодить.

> Ожидаемые трудозатраты (см.ниже)- один человеко-месяц. Садись, пиши, внедряй.
> А что до всех этих игр с make. Ну да. Забавно. А еще на make можно пирожки печь.

Я думаю, что оценка трудозатрат несколько оптимистична.
Особенно в виду того, что процесс #1 не может ошибаться.

> В одном моем проекте была сходная задача - импорт продуктов, с зависимостями.
> Написание с нуля заняло пять рабочих дней, вместе с отладкой. По функциональным
> точкам, там было примерно половина от того, что нужно для задачи старта сервисов. 
> Учитывая многочисленные согласования с унаследованной средой, для задачи старта
> сервисов потребуется, наверно, месяц. И мое мнение - нужно сразу брать курс в этом
> направлении, а не заниматься гробокопательством и гальванизацией трупов в лице
> initscripts & inittab.
> 
> Сразу замечу, что всяческие проблемы с унаследованным софтом, при таком подходе
> можно решить достаточно легко и непринужденно, особенно если делать это
> на уровне дистрибутива. И сбсно мне кажется, что даже руки которые сделают
> это найдутся сразу, как только такое решение будет принято.

Интересно, как же это они найдутся?


--
ldv