Минимально-достаточный функционал системы инициализации

а вообще, вот мой список:

• Запускать демоны. Ваш К.О.;
• Уметь в ранлевелы (хотя таргеты из systemd лучше);
• Уметь в Cgroups
• Забирать себе процессы, родители которых умерли;
• Уметь в зависимости демонов;
• Уметь в параллельный запуск;
• Выключать и усыплять комп.

и да, если дойдет до написания сабжа, я участвую.

Не спеши. У меня уже потихоньку формируется список фич.
Когда этот тред умрёт, то я их смержу и создам новый тред — на базе полученного списка будет легче увидеть какие фичи избыточны, а каких не хватает.
Возможно через несколько итераций мы получим вменяемый список функций.

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

Я, например, испытываю затруднения, включая и выключая весь OpenERP через службу сервисов windows (Postgres, OpenOffice в безголовом режиме, OpenERP). Если бы у меня был простой командный файл, запускающий постгрес, ОО и ерп последовательно, а потом их также вырубающий, мне было бы легче. Да, в моих потребностях нету мегаэнтерпрайза, да, я могу сделать командный файл, дёргающий сервисы. Но ЗАЧЕМ? Мне не нужны сервисы, мне нужна пара программ, слушающих пару портов.

Сразу могу сказать, что зависимости избыточны. Они нужны только в погоне за скоростью. В результате инит и конфиги демонов усложняются.

Кстати, хорошая идея возникла, различать демоны и сервисы.
Сервис - это какая-то НЁХ, большого размера, зависящая от много чего, которая не поддаётся достаточному отстрелу багов (Бернштайн срёт кирпичами при виде этого интырпрайз софта), и требует супервизора.
Демоны - это простые резидентные программы, не требующие супервизора.

В принципе, на локалхосте сервисы вообще нфиг не нужны.
(в данный момент единственная выгода локалхоста от systemd - параллельная загрузка).

зависимости избыточны

Я бы не был настолько категоричен. Например некоторые мои проекты состоят из нескольких демонов и желательно запускать их последовательно, поскольку следующие коннектятся к предыдущим.

Ты думаешь формирование определения, скажем, окружности проходило без срача?

думаю, что несогласных убивали. Всё было по результатам реальных действий, а не по результам обсуждений и срачей не было.

Вот например в Камбодже определение правильной религии завершилось победой шиваистов над буддистами. Хотя казалось бы...

параллельная загрузка

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

Я предлагаю никого не убивать на ранних этапах обсуждения. Хорошо?

Ну так я примерно к этому и веду. Все демоны без зависимостей запускаем параллельно (дефолт). Демоны с зависимостью запускаем по списку, по очереди. Но без попыток разруливать такие вещи автоматически или запускать часть демонов с зависимостями параллельно, часть последовательно.

Сами зависимости можно в отдельный конфиг вынести, чтобы не размазывать по конфигам отдельных демонов.

я просто хотел сказать, что определение окружности формировалось путём передачи тайного знания. Вон даже Пифагорейская школа ещё прятала свои секреты.

Вполне жизнеспособно.
Но я предлагаю отложить обсуждение этого вопроса на тогда, когда список фич будет «утверждён» и мы перейдём к обсуждению зависимостей если таковые вообще будут.

http://fs42.www.ex.ua/get/103163732/26137799146111_-gif-nachalnik-it-ofis-115...
Вот вам картинка для привлечения внимания и поддержания интереса к треду.

Т.е. демон, работающий с дибасом уже сервис?

Кстати, я бы тоже поучавствовал в девеле. Запишите меня.

Есть еще один момент. На чем писать конфиг демона?

На баше удобно в том смысле, что админу не нужно изучать новую сущность раз и сразу в конфиг удобно вставляется скрипт «что делать если...» два. А еще в init не нужно вставлять парсер+интерпретатор.

На DSL удобно, потому что:

1. Можно написать утилиту проверки корректности конфига.
2. Конфиги короче.
3. Меньше(?) вероятность написать фигню в конфиге.
4. Теоретически разбор такого конфига может быть быстрее.

Минусы очевидны: нужно придумать DSL, учить его, чтобы писать конфиги, придумать как вставлять туда куски скриптов на bash, написать парсер итд итп.

Мое имхо, если и делать конфиг не на баш-скриптах, то только при условии что DSL минимален. Полный ман с описанием всех мелочей должен быть страниц на 5 максимум.

Инит пишется для админов. Следовательно должен быть понятен любому админу.
Я за то чтобы специфические (т.е. те о которых сам инит не имеет никакого понятия) фичи для конкретного демона были на баше.
Создавать язык специально для одного лишь инита? Да ну. Кто же этим будет пользоваться-то?
Или я неправильно понимаю аббревиатуру DSL как domain specific language?

event driven, triggers, fsm, sandboxing, busyboxing, (user)plugins, introspection, dev-lang support, declarativity, erlang like processes/processing, comprehension distro-API/supporting, gentoo-like-and-maybe-based

Разверни пожалуйста мысль.
А то слова вроде erlang и gentoo-like-and-maybe-based вызывают опасение, что ты не понял что мы тут обсуждаем...

Вы все правильно поняли. Я просто хотел разложить по полочкам. А то сейчас придут системдещики и будут рассказывать, какие там классные и простые конфиги.

Насколько я понял (сам я пока системД не щупал) там как раз общий и базовый функционал (start/stop/reload и т.п.) возложен на инит, а демоноспецифические вещи на баше.
Вполне разумно если это так.

Как только dbus станет частью ядра, то не обязательно.
Если демон лезет общаться с развесистым кустом сервисов через dbus, то 100% сервис.
Еси демон спрашивает у кернела состояния - то демон.

Не на баше, на базовом sh.
Вообще, «простыня» с комментариями и переменными - очень легка в понимании и использовании. Ну и сделать возможность хранить в gz.

sh

Ну логично. Просто баш сам из-под пальцев выпечатывается.
Разумеется имеет смысл ограничиться лишь общими для всех шеллов вещами (тем более, что вряд ли это принесёт какие-либо неудобства).

Плюсую ограничение базовым sh, чтобы запускалось на любом шеле. Опять же, можно написать функцию, которая это дело будет проверять и если что бить по пальцам.

А зачем сжимать? Профита от этого сильно много? Ладно там в один tar отдельно пихать start/stop скрипты.

Разверни пожалуйста мысль.

А то слова вроде erlang и gentoo-like-and-maybe-based вызывают опасение, что ты не понял что мы тут обсуждаем...

Это ключевые слова (маркеры).

Если сделать систему инициации на эрланге или в его идеологии (кластерность, gen_fsm, gen_tcp/udp, snmp, inets, многопоточность (параллелизм, красивый), ноды, супервизоры - все эти плюшки прямо из коробки) Только вот к сожалению ерлангу при старте наверное нужна сеть и ФС сразу - не совсем понятно как это будет работать на уровне инита. Наверное от этой зависимости не избавится.

Но плюсы: ФП, иммутабельность, сетевая прозрачность, понятность, отлаживаемость, легковесные процессы, отказоустойчивость, компиляция в бинаршину, горячая замена кода на лету. Хотя-бы не инит, а окружение какое-то. Жалко ведь игнорировать такие возможности богатые.

Насчет генты - нужно черпать там вдохновения во всем от rc_init до портажа...

Как только dbus станет частью ядра

надеюсь, до этого не дойдет.

А в чем смысл различать демоны и сервисы? Есть какая-то большая разница в том, как ими управлять? И то и другое запускается в основном при запуске системы и делает что-то полезное. Я вижу лишь особенность, если демон порождает дочерние процессы.

У лиспа тоже всё это есть, но кто будет всё это писать-то на эрланге или лиспе?
Посмотри вокруг. Никто и на Си писать-то инит не рвётся, а ты говоришь эрланг.
И так вокруг зоопарк Си-жаба-моно-питон-х.з.что.
Я бы писал на Си и не мучил ни людей ни себя.

Имхо, такие фичи как «горячая замена кода» для инита ну совсем не нужны. Да и эрланг системным языком не является. Писать такие вещи имеет смысл на чистом Си.

Есть огромная разница. Демоны нужно только запускать, из даже не всегда нужно корректно останавливать.
Сервисы нужно запускать с зависимостями, мониторить их состояние, при необходимости перезапускать, логи собирать и сохранять вместе с coredump в энтерпрайзной db.

kdbus - это уже неизбежность.

Конфиги сжимать - просто чтобы в сравнении с systemd они не казались большими.

Инит не обязательно должен быть написан на sh!
Его конфиги должны быть на sh, можно даже урезанном.
Т.е. логика, переменные, инклады и т.п. - как в sh.
Просто чтобы не путать админов.

ну тогда питон, баш идеи генты.

В идеале одна кодовая база. Но это сложнее т.к. нужно будет мини-ядро генты везде таскать, хотя при современном размахе...

Все что нужно - это очень качественно продумать кодовую базу в ключе контроля версий. Чтобы это лежало на гитхабе и разворачивалось одним пинком. Легко отлаживалось и деплоилось. Чтобы вовлекалось в процесс как можно большее число разработчиков.

Качественная документация. Условия для развития мантейнерами. Легкая и приятная интеграция в разные дистры.

Готовые кастомные сборки и решения. Тестовые наборы для виртуалок и контейнеров с докерами.

Как только dbus станет частью ядра, то не обязательно.

изыди!

Мониторить состояние демонов тоже необходимо. Неприятно, если отвалится что-то нужное. Про зависимости я писал выше, просто в отдельном конфиге перечисляем, в каком порядке запускать некоторые из демонов.

Писать логи должны сами демоны в удобном для них виде. Это явно не задача инита, знать о существовании «энтерпрайзной db».

Так что разницы я тут не вижу. Пожалуй так лучше всего для простого инита, чтобы ее и небыло.

Имхо, такие фичи как «горячая замена кода» для инита ну совсем не нужны.

Могу конечно ошибаться, но:

А /etc/init.d/ разве не входит туда?

А запуск сервисов оттуда это уже не инит?

Хотя в генте с этим в принципе баш и питон на 6+ справляется... Но для любителей можно было бы допускать и другие языки.

ерланг для инита это перебор ящитаю.

компиляция в бинаршину,

это в ерланге то?

Кажется тут проблема терминологии. Под инитом я имею ввиду сам инит, который запускает демоны в соответствии с конфигами в /etc/init.d/. Тоесть init читает конфиг демона и выполняет из него скрипт start на баше.

компиляция в бинаршину,
это в ерланге то?

beam-ов нет разве уже?

ерланг для инита это перебор ящитаю.

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

kdbus - это уже неизбежность.

Линус сопротивляется. Поглядим, что из этого выйдет.

Конфиги сжимать - просто чтобы в сравнении с systemd они не казались большими.

Важны не килобайты, важны строчки кода. Вот если конфиги весят 10 метров - тогда да, есть повод задуматься о сжатии.

А питон по сравнению с башем какой overhead дает по памяти/скорости? Какие части ФС нужно смонтировать, прежде чем питон сможет работать?

А питон по сравнению с башем какой overhead дает по памяти/скорости? Какие части ФС нужно смонтировать, прежде чем питон сможет работать?

Без баша и busybox будет еще тот секас имхо...

Так бимы это код для вм, не? Сейчас только hipe есть, но он всё равно без вм не фурычит насколько мне извесно.

Были новости о том, что один чел сделал вм, работающиюю прямо поверх xen, без оси, но там проприетарное решение. Я вот всё жду, когда сделают опен сорс, сильно охота на это посмотреть.

А вообще, ерланговский процессы от юниксоидных мало чем отличаются с точки зрения супервайзеров. В юниксе можно так сделать обработчик sigchld и будет простой супервайзер. Обмен данными огранизовать через stdin/stdout. Если stdin закрыли (родитель умер), то дочерний закрываемся. Чем не spawn_link? Только такой подход имеет тот недостаток, что сложно сделать distributed application (наверное даже не возможно без костылей) и боюсь обмен данными через sysV ipc будет медленее, чем Pid ! {ping, self()} какой-нибудь.

Кстати whatsapp -оский сервер говорят на ерланге написан. Вот это вот я понимаю масштабирование. А то нодежс, нодежс.

продолжу свои хотелки:

1. модульная архитектура. ядро реализует только базовый функционал, скажем, по запуску/перезапуску/остановке демонов. хочется других фишек - реализовать через плагин

2. текстовые конфигурационные файлы в стиле имя_сервиса:

[базовая секция]
параметр1 = значение1
параметр2 = значение2

[дополнительная секция]
парамерт3 = значение3

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

4. если необходимо реализовать какую-то логику или переопределить встроенный алгоритм (скажем запуск/остановка сервиса), то в качестве параметра задается скрипт. скрипты кладутся в каталог имя_сервиса-scripts

успехов тебе!

Это же win.ini конфиг!
Квадратные скобки могут быть комментарием.
Так мы пришли к sh.

хочется других фишек - реализовать через плагин

Ну дык скрипт же! Что хочешь, то и пиши.
Просто базовые вещи будут уже написаны.
Ок. Завтра я создам новую тему в которой будут собраны все хотелки отписавшихся.
Я не верю в отсутствие срача, но надеюсь на конструктивный срач!
Плотно поужинай, чтобы завтра было чем метать во врагов:)

пришли к sh

Хотя обсуждение языка скриптов и выходит пока за рамки, но мы никуда от sh и не уходили.
Мы творим эволюцию, а не революцию.
Мы не хотим разрушать фундамент. Мы надеемся(хотя и обсуждаем это), что мы можем построить «нойе орднунг» на существующей базе:)

Да, ещё такая мысль: github хорошо, но архитектуру мы там не построим. Диаграммы, блок-схемы и т.п.

Какой-такой гитхаб?
Никто про гитхаб пока и не говорил. Не спеши.
Давай пока определимся с тем ЧТО делать.
Сформулируем задачи. Определим функционал. А когда начнёт что-то вырисовываться, то и площадка найдётся.

Сами зависимости можно в отдельный конфиг вынести, чтобы не размазывать по конфигам отдельных демонов.

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

да хоть знаком интеграла секции выделяй! главное смысл:)