From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 21 Sep 2003 23:49:30 +0400 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?2sHQ1dPLINPF0tfJ?= =?koi8-r?B?08/X?= Message-ID: <20030921194930.GA23878@basalt.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20030919112708.B75629@elefant.dgtu.donetsk.ua> <200309191835.24082.cray@neural.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <200309191835.24082.cray@neural.ru> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2003 19:49:31 -0000 Archived-At: List-Archive: List-Post: --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/bgDK9viEa8HiNCkRAvTUAJ4lhnWFCqffo7SY39jrXs0xVBnS0QCeMN0M bCuDexXVc9ve/qFR7Ge/Lao= =latu -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--