[devel] запуск сервисов
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Вс Сен 21 23:49:30 MSD 2003
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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20030921/be1f04c7/attachment-0001.bin>
Подробная информация о списке рассылки Devel