Представлен выпуск сервисного менеджера s6-rc 0.5.6.0, предназначенного для управления запуском скриптов инициализации и сервисов. Поддерживается отслеживание дерева зависимостей и автоматический запуск или завершение сервисов для достижения указанного состояния. Инструментарий s6-rc может применяться как в системах инициализации, так и для организации запуска произвольных сервисов в привязке к событиям, отражающим изменение состояния системы. Система поддерживает скрипты инициализации, совместимые с sysv-init, и может импортировать информацию о зависимостях из sysv-rc или OpenRC. Код написан на языке Си и распространяется под лицензией ISC...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63187
Какая-то она мудрёная. Из всех альтернатив Systemd больше всего мне понравился Runit - он очень быстрый и простой, как палка.
да, но не трекает зависимостей. А если их трекать, то всё усложняется, и минимальный вариант усложнения - это s6.
минимальный - openrc.
или даже чтоУгодно+startpar.
да, скорее так.
dinit мне показался проще и быстрей, чем s6.
sinit*
>да, но не трекает зависимостейКакие ещё зависимости? Запустить, остановить демона. Статус энэбл и дисэбл. Что ещё нужно для счастья? Ничего.
>А если их трекать, то всё усложняется, и минимальный вариант усложнения - это s6.
Какой ещё от запускальщика демона усложнение? Вы в своём уме, или вас systemD развратил.
А подумать никак?Сервис может зависит от другого сервиса, а тот зависит от нескольких других.
Как пример
Сервис логировниия Х, логика которого инициализировать и запустить что-то, а это что-то передает данные по сети.
Перед тем как запустить этот сервис, нужно инициировать и запустить сервис управления сетью.
И так далее по цепочке.
а почему нельзя сразу написать нормально так, чтоб логирование запустилось без сети и ждать его появления?
самая никчемность подхода зависимостей - когда сервис сети поднят, а связи по факту нет, потому что обрыв, фаервол и все такое.
аналогия: у тебя есть машина, но оказалось проколото колесо. поэтому давай снимем все колеса, разберем двигатель и сожгем кузов
> а почему нельзя сразу написать нормально так, чтоб логирование запустилось без сети и ждать его появления?Зависимости бывают разные. Бывают времени работы программы - когда сеть нужна тебе для выполнения запросов, и ты просто посылаешь отказ, если сети нет. А бывает зависимость, необходимая для старта, если например из той сети берётся конфигурация. И тут уже никак - без сети ты не знаешь какие порты открывать, каким пользователям разрешать делать запросы - и прочее, а по умолчанию разрешать всем - это очень плохая идея.
А ещё зависимость нужна чтобы не запускать десяток сервисов вручную. Запускаешь один - остальные запускаются автоматически в вычисленном порядке или параллельно.
> а почему нельзя сразу написать нормально так, чтоб логирование запустилось без сети
> и ждать его появления?Вопрос: как запускать допустим сервер желающий забиндиться на конкретный интерфейс, до того как он появился и сконфигурен? А биндиться к конкретному адресу тогда вообще как? Вот запустили мою прогу. Ифейса нет. И?
из альтернатив сд, как сервисному менеджеру, только openrc и s6.
остальное даже не близко по функционалу
Shepherd забыл?
Shepherd это шик, единственный инит, который я действительно понимаю)
> Какая-то она мудрёная. Из всех альтернатив Systemd больше всего мне понравился Runit
> - он очень быстрый и простой, как палка.На этом его достоинства и заканчиваются. Ибо никакая он не альтернатива системде по возможностям даже и близко. А простота бывает хуже воровства в вопросах прода и его поддержки.
Третий год как без системд, никакие из его возможностей ни на моём локалхосте, ни на роутерах и прочих малинках так и не понадобились. Везде активно юзаю LXC и неймспейсы, на некоторых роутерах в особенности, где автоматический роутинг на недружественные адреса через впн.Runit - это отдельная песня. Во первых, настоятельно рекомендую заглянуть в его исходники, ужаснуться, и никогда не пользоваться. Во-вторых, советую держать /etc в tmpfs (overlayfs в помощь) или мониторить дисковую активность, иначе своей дебильной системой управления сервисами он может легко убить SSD.
> Третий год как без системд, никакие из его возможностей ни на моём
> локалхосте, ни на роутерах и прочих малинках так и не понадобились.А вот когда у вас будет этих локалхостов побольше - и посмотрим как вам оно. Особенно если наруленых не вами.
> Везде активно юзаю LXC и неймспейсы, на некоторых роутерах в особенности,
> где автоматический роутинг на недружественные адреса через впн.А вон там мужик на кляче в правом ряду вообще тошнится, на деревянной телеге. Ему такому наверное и локалхост не надо. Зажег лучину - и порядок.
> Runit - это отдельная песня. Во первых, настоятельно рекомендую заглянуть в его
> исходники, ужаснуться, и никогда не пользоваться. Во-вторых, советую держать /etc в
> tmpfs (overlayfs в помощь) или мониторить дисковую активность, иначе своей дебильной
> системой управления сервисами он может легко убить SSD.Я умею пользоваться системным мониторингом, спасибо. И пакет iotop-c у меня в почете, на всякие странные случаи. Но расколупывать runit или кого там конечно за это не считаеися, мне жаль на такое время грохать.
> что позволяет выполнить ресурсоёмкий анализ зависимостей отдельно, а не во время загрузки или изменения состояния.У них там что, десяток тыщ сервисов или это опять классический "premature optimization"?
С системдой же не за 5 секунд загружается, хотя и с ней не сотнями сервисы грузятся.
скорее всего затачиваются под встроенные системы. Там частенько делают переконфигурацию через перекомпиляцию.
даже для 10 сервисовэто дает ощутимый прирост.
openrc тоже зависимости для нативных сервисов компилит. и стартует их одним openrc-run'ом, запущенным 0'м пидом.
результат - прирост в 4 раза по сравнению с ненативными.
> даже для 10 сервисовэто дает ощутимый прирост.
> openrc тоже зависимости для нативных сервисов компилит. и стартует их одним openrc-run'ом,
> запущенным 0'м пидом.
> результат - прирост в 4 раза по сравнению с ненативными.Только речь о "затратах" на анализ, а не о способе запуска (из-за чего, скорее всего и "прирост").
Внимательно следите за руками:
https://man.freebsd.org/cgi/man.cgi?rcorder(8)
> The rcorder utility is designed to print out a dependency ordering of a
> set of interdependent files. Typically it is used to find an execution
> sequence for a set of shell scripts in which certain files must be executed before others.построение графа:
% time rcorder /etc/rc.d/* /usr/local/etc/rc.d/* |wc -l
198 <-- 198 сервисов
rcorder /etc/rc.d/* /usr/local/etc/rc.d/* 0,00s user 0,01s system 79% cpu 0,007 totalАнализ для "оптимизации" (т.е. там еще предыдущий анализ):
> -p Generate ordering suitable for parallel startup, placing files that can be executed simultaneously on the same line.
% time rcorder -p rcorder /etc/rc.d/* /usr/local/etc/rc.d/* |wc -l
47
rcorder -p rcorder /etc/rc.d/* /usr/local/etc/rc.d/* 0,00s user 0,01s system 78% cpu 0,009 total
> У них там что, десяток тыщ сервисов или это опять классический "premature optimization"?Да.
основная цель не в оптимизации, а в том чтобы вынести код со сложной логикой (парсинг, построение графа зависимостей и т.п.) в отдельный бинарник, который не выполняется во время загрузки системы.Таким способом снижается поверхность атаки и количество потенциальных уязвимостей. Понимаю, необычно, когда таких целей достигают изменением архитектуры программы, а не ее тупым переписыванием на раст.
> Утилиты для отслеживания, набор утилит для создания, обвязка для воссоздания, набор типовых утилит, другой набор утилит, менеджер событий, сетевой конфигуратор, язык написания сценариев, библиотека для создания невозможного, набор клиентских библиотек и утилит, DNS forwarder, DNS-сервер, HTTP-серверНо комбайн — это systemd. Смотри не путай!
В s6-rc модули независимы, а в systemd они не работают отдельно друг от друга, поэтому да, systemd - комбайн
> В s6-rc модули независимы, а в systemd они не работают отдельно друг
> от друга, поэтому да, systemd - комбайнНезависимы от чего? Это может работать без s6? С другими инитами? Или... ?
да, может.
я больше Вам скажу: у openrc, напр., даже поддержка s6'ого супервизора нативная, через supervisor=s6(или как-то так).
> да, может.
> я больше Вам скажу: у openrc, напр., даже поддержка s6'ого супервизора нативная,
> через supervisor=s6(или как-то так).Как говорится в следствии из законов Мерфи...
... сделайте систему где можно настраивать 200 параметров, и вы БУДЕТЕ настраивать все 200 параметров, лично. Независимо от того хотели ли вы этим заниматься.
...то есть systemd. В котором я БУДУ настраивать ресолв, лидсвитч и всё остальное и материться в противовес любому другому иниту. На голом runit на дебиане столько боли не было, чтобы запуститься и не ловить удивление от дефолтов, сколько на системд после обновления.
> ...то есть systemd. В котором я БУДУ настраивать ресолв, лидсвитч и
> всё остальное и материться в противовес любому другому иниту.В дебиане можно вообще не ставить нетворкд и проч. А journald - mask например, если уж хочется совсем странного и пофиг на диагностируемость ОС. И тогда настраивать все же не 200 параметров, а сильно меньше.
> На голом runit на дебиане столько боли не было, чтобы запуститься и не
> ловить удивление от дефолтов, сколько на системд после обновления.На голом runit боли будет потом по многим другим поводам. Особенно если сервак не мой - окей и как понять кто откуда тут вообще взялся? А если это прод и надо рестартовать упавшее и повисшее на автомате - во скольких закоулках будут конфиги? Это все круто - пока вы холите и лелеете лично ваш локалхост. Один. А чуть за пределы этого - и совсем оно не круто уже, #$%ться в цатый раз с типовой проблемой самому, изобретая квадратное колесо, как оптимизацию треугольного, с аргументом что оно еще хуже было.
Вполне могут, ровно настолько же, насколько это поделие, не считая мелких брызг. Проблема с хейтерками не в том, что им что-то не нравится (мнения — они как задницы, у каждого есть своя), а в том, что хейтерки сами не знают что они хейтят и почему, и от того придумывают для оправдания «комбайность», «философию юникс» в собственной произвольной трактовке, и прочий шаманизм. Но вот поди ж ты, оказывается инициализация системы это нетривиальная задача,
и её решение в общем случае требует нетривиальных программ. Quelle surprise!
кто-то ниасилил матчасть и пошел рассуждать прохейтеров ?
какая милота !
> кто-то ниасилил матчасть и пошел рассуждать прохейтеров ?
> какая милота !Я другой анон, но если говорить за матчасть то systemd просто и элегантно решает вопросы с изоляцией, сменой пользователей, урезанием прав, настройкой шедилунга и приоритетов, построением кастомного view системы и много чего еще - несколькими директивами конфига, и это не трансформируется в ломкие, сложные, медленные действа уповающие на доступность того или иного закоулка системы.
Потому что технически очень удобно иметь привилегированный агент который отвесит все нужные сисколы в правильном порядке.
А юниксвэй это прекрасно. Но - не в этом случае. А забивать гвоздь микроскопом - потому что вэй так требует - да ну нафиг. Иногда лучше обойти такой вэй сторонкой, и взять молоток. А если гвоздей много то и крутой пневмомолоток. После чего мы поговорим о продуктивности работы и кто сколько времени на одну и ту же задачу тратит. Это интереснее чем абстрактные разссуждения о абстрактных вэях. Задач много, а жизня - одна.
вот Вы сначала определитесь, удобно Вам сервсивный, системный менеджер или "linux userspace API 2.0".
и потом уж рассуждайте.
а все вместе, пропихиваемое под эгидой "сервисы будут быстрее стартовать" - это мало того, что обман, так еще и шерето.
если решите указать, что компоненты отдельно работают и друг от друга мало зависят - то и обсуждайте их отдельно, а не так, что "сд вообще-то модульный", как кто-то начинает про монолитность, и "ну вот удобно, хороший апи, сисколы в ряд для всего на свете", когда кто-то тыкает, что другой сервисный менеджер был с идентичным sd(как серв. менеджеру) функционалом еще задолго до появления последнего. с той лишь разницей, что с openrc куча народа из рх не бегало и гентушников в свое время в тех. коммитете дебиана не завалялось.
а еще в то, что мистер леннарт об openrc в своем сравнении инитов тактично умолчал.
> вот Вы сначала определитесь, удобно Вам сервсивный, системный менеджер
> или "linux userspace API 2.0".Голыми руками дергать сисколы - несподручно! Значит какие-то программы нужны. А раз так - пусть изволят работать нормально. Полноценно раскрывая фичи ядра и реализуя мои хотелки, типа: пустить этот httpd в пустом view, под нужным юзером, с нужными лимитами, где нет по сути ничего кроме wwwroot и его конфигов, запрещены сисколы кроме нужных ему, no new privs, никакого доступа в реальный /dev системы и прочие bash (нафиг оно httpd?!).
Так что если httpd и облажается - не сможет выполнить баш. Его там нет! И за wwwroot выйти - тоже! Потому что теперь это его / и есть. Так что GET ../../../../etc/passwd немного обломается. Вот хоть как.
И вот тут есть большая разница. Системд от рута висит и может все сисколы для вон тех вещей секвенсировать сам, собирая арену будущему процессу. А кучка утилиток - имеет проблему. Они не резидентны в памяти. А на середине действа большая часть системы - становится недоступна. В этом месте юниксвэй немного ломает ногу. Чисто технически.
> и потом уж рассуждайте.
Я просто умею в системное программирование - и когда-то сам писал костыли для примерно вон того. А теперь я могу этим не заниматься, ибо вел с квадратными колесами и ОТДЕЛЬНОЙ конфигурацией - такое себе. Хорошо что кто-то нашел ресурсы сделать 1 раз менее криво и - для всех.
Конфиги для ОДНОГО И ТОГО ЖЕ ПО СМЫСЛУ раскиданые в дюжине закоулков - это капец. В именно классическом юниксвее обозреть состоения системы это жесть и ужас. В системд пнуть один несчастный systemctl. В классическом юниксвее не предусмотрено НИЧЕГО сравнимого. И просто понять "откуда это запускается и как поменять там что-то" может занять энное время. Без уверенности что пакетник при апдейте это при случае не перетрет.
Если вы окучиваете 1 локалхост это пофиг. Но у меня даже на локалхосте - с дюжину VM, а еще куча мелких железок, и проч. Мне как - весь этот флот фетровой тряпочкой так полировать? Я что, живу вечно? Или я должен от и до помнить содержимое их всех? Этот подход - не масштабируется.
> а все вместе, пропихиваемое под эгидой "сервисы будут быстрее стартовать" - это
> мало того, что обман, так еще и шерето.Я думаю что у вас на практике будет куда большее шерето - потому что вы вообще не разопретесь вон то нарулить. Или это будет требовать нездоровое время на эту задачу, для достижения того что я делаю за 5 минут.
И таки - вон то нормальное управление системой. Когда я могу запилить мой сервис за 5 минут и не получать потом граблями типа "логротейт не настроили - место через год кончилось". Да, бинарные базы кроме всего прочего можно 1 раз нарулить работать в режиме кольцевого буфера по сути. Фиксированного размера. Это гарантирует хранение максимума полезного - в пределах пространства которое я готов на это выделить.
В логротейте же... как обычно лоскутные одеяла и надо каждой прожке внимание самому уделять, явно подписывая прожку на это дело. Половина про это забудет а потом вон там на серваке место что-то кончается. С системдой мы просто забыли о такой фигне.
> если решите указать, что компоненты отдельно работают и друг от друга мало
> зависят - то и обсуждайте их отдельно, а не так, что
> "сд вообще-то модульный", как кто-то начинает про монолитность,Вообще при желании...
1) Ну я и не ставлю допустим networkd. Не нравится мне как он работает я им и не пользуюсь. И нечего мне за это не бывает.
2) На некоторых системах (эмбедовка) у меня и journald нету. В основном из соображений сохранности флешки и/или readonly / большую часть времени при работе.
3) В особо хардкорных случаях в списке процессов бывает systemd, getty и bash.> и "ну вот удобно, хороший апи, сисколы в ряд для всего на свете",
Сисколы - это то как работает система. Вызывать их можно разными способами, с различной степенью дурацкости. А вот что я не собираюсь - так это нагревать себя на современные возможности ядра во имя вэев или какой там еще луны. Если какой-то инструмент где-то плохо работает - надо доработать инструмент или заменить его, а не пытаться упорно фигачить любимым микроскопом - по железнодорожному костылю, во имя хз чего.
> когда кто-то тыкает, что другой сервисный менеджер был с идентичным sd(как серв.
> менеджеру) функционалом еще задолго до появления последнего.У кого из них есть нормальный обзор системы и отсутствие logrotateпроблем на пару с нормальным логингом фэйлов?
> с той лишь разницей, что с openrc куча народа из рх не бегало и гентушников
> в свое время в тех. коммитете дебиана не завалялось.Я лично вообще не понимаю какие проблемы это недоразумение решает. А гентушники никогда не были известны мне рациональным mindset, уж извините. Они всегда убивали море времени на страдание фигней, как в песенке про мельника - "он потратил шиллинг, заработал грош" (это про нагрев проца компилом всего VS выигрыш от оптимизаций после этого). А дебиан я юзаю потому что там тима более прагматично ориентирована.
> а еще в то, что мистер леннарт об openrc в своем сравнении
> инитов тактично умолчал.И черт бы с ним! Ума не приложу зачем мне это подобие автомобиля с торчащими оглоблями. Я вообще не понимаю какие проблемы он решает. И совместимость с окаменелым д@рьмом из 70 прошлого века - в ущерб самым базовым кейсам - мне как-то так себе.
Понапридумывают сложнейших систем с кучей сопутствующих пакетов. А могли бы уже просто взять ясное и прекрасное творение Линуса Поттеринга - systemd, и не парить себе голову. Всё легко и просто загружается, настраивается, поддерживается.
Линуса Поттеринга..Ну теперь все встало на свои места.
Вот это поворот!
Vendor lock - это плохо. Нужны альтернативы.
Никакого вендролока - с systemd полная свобода! Линус Поттеринг - радетель СПО, его творения свободнее многих иных систем.
Линусу было нас рать, а вот Лёня мог улучшить openrc, а не городить своё.
Нет. В openrc, по большому счёту, улучшать особо и нечего.
Идея заменить скрипты на shell (т.е. инструмент общего назначения, приспособленный для решения специфической задачи) на специализированный инструмент - вполне здравая. Проблема в том, что Лёня - классический shitfinger, он превращает в фекалии всё, к чему прикоснётся. Все его творения - и авахи, и пульсу, и системд, пришлось доводить до ума другим людям.
> пришлось доводить до ума другим людямСомнительно они это довели до ума, ну серьезно - просто набор костылей прикрутили
> пришлось доводить до ума другим людямА почему «другие люди» не довели до ума что-то другое? Почему взяли то, что написал Поттеринг, а не что-то другое или вовсе своё написали?
Ну, в случае пульсы - таки нашёлся герой, который решил, что нуевонафиг и написал пайпвайр. Системд - скорее всего потому что больно уж большой объём, чтобы вот так вот всё похерить и начать с нуля. А вот почему авахи до сих пор не заменили на что-то, что позволило бы не соединять все географически разнесённые сети в одну л2-бродкаст-помойку - для меня загадка.
> Системд - скорее всего потому что больно уж большой объёмНе нужен там большой объем. Особенно оставить инит инитом. Примером тому является, например, dinit.
> А вот почему авахи до сих пор не заменилиВидимо, потому что он тихо-мирно работает в уголке и жрать не просит. Да и нужен не только лишь всем.
так в openrc уже 10 лет, как никакими скриптами на шелле не пахнет.
в openrc все то, что было в systemd, чуть ли не с самого его начала.
включая декларативные сервисы, зависимости, быстрый запуск(используя 1 процесс-запускатель при инициализации, вместо исполнения всего init.d).
просто в openrc это было сделано с оглядкой на обратную совместимость и удобство.
Вы вполне можете вставить шелл-код в сервис или положить бинарник в init.d.
но так редко делают.
это к слову о том, почему леннарт в своем сравнении рассматривал только upstart и sysv, когда sd еще был сервисным менеджером.
> так в openrc уже 10 лет, как никакими скриптами на шелле не пахнет.Это ему уже не поможет. Он как был кучей костылей и подпорок, решающий фиг знает какие задачи/проблемы, и почему именно так - таковым навечно и останется.
Прелесть системды - в том что 1 компактным конфигом решается довольно много довольно сложных системных задач. Которые напряжно решать кучкой утилиток, скриптиков и проч. Ибо если я собирал изолированную от системы арену, система by design недоступна. И я не вижу причин оставлять веб серверу доступ в шелл, утилиткам сервис менеджера или что там - явно не требующееся для нормальной работы, это только хакерам удобнее делает. А с юниксвеем проблема в том что оно где-то в середине действа завалится по причине "утилитки - недоступны". Системд в памяти висит, с правами, и может сисколы отвесить не уповая на все эти лоскутки в закоулках. Так что у него такой проблемы нет.
А вон там получается - жутукий франкенштейн, кривой, сложный, ломкий, с кучей особенностей и факапов, "зато забили гвоздь ЛЮБИМЫМ МИКРОСКОПОМ".
> в openrc все то, что было в systemd, чуть ли не с
> самого его начала.У системды также есть кроме вышеупомянутого:
1) Нормальный обзор статуса системы. Я 1 утилитой могу глянуть ок ли моя система. Есть ли сбоящие сервисы. Вот это все. А еще парой - время старта и анализ кто систему клинил.
2) Нормальный логгинг, когда
2а) мне не надо греть мозги долбаным logrotate на каждый первый сервис
2б) если сервис не взлетел то коды возврата, сообщения stdout/stderr и проч в логах
3) Тулинг для типовых задач. Хочется рулить контейнеры или виртуали? Есть утилсы для этого. И это одинаковое на всех дистрах с системд. Т.е. на львиной доле линухов.
4) Вещи полезные в необслуживаемых/малообслуживаемых системах и эмбедовке. Нокия называла это mission control. Включает в себя трек успеха загрузки и информирование бутлоадера, реакцию на сбои сервисов, работу с аппаратным вачдогом и проверку что сервисы которых оно супервизит реально живы, а не плймали локап неделю назад при всеобщем пофиге на все и вся, как вон там.И как у вас дела с этим всем? Да, системный менеджер это не только про запуск. Это еще про "супервайзинг" системного "здоровья" и того что запущено. И крайне тупо настраивать ЭТО где-то отдельно от вон того, ибо плотно связанные вещи. Нормально увязать это может кто-то имеющий хоть какой-то скилл архитекта. У поттеринга он был, уж какой-никакой. У вон тех была только бездарность и безблагодатность на эту тему имхо.
> включая декларативные сервисы, зависимости, быстрый запуск(используя 1 процесс-запускатель
> при инициализации, вместо исполнения всего init.d).Лично я очень рад что забыл про init.d как страшный сон. И теперь у меня нормальное управление системой а не пародия из спичек и желудей, "зато свое!".
> просто в openrc это было сделано с оглядкой на обратную совместимость
На мой вкус я не буду скучать о совместимости с тем мусором из 70-х. Зачем в авто оглобли для запрягания лошадей?!
> и удобство.
Что вы в этом вообще понимаете? С вашим микроменеджментом tomoyo вы делом показали - ничего. Нормальные люди для ТОГО юзают контейнеры и достигают резульат не хуже а может и лучше - с возней в десятки раз меньше. И вы после этого будете говорить про удобство? :)
> Вы вполне можете вставить шелл-код в сервис или положить бинарник в init.d.
Что обрекает тех кто будет эти системы майнтайнить, если это не локалхост, на неприятные сюрпризы. Чаще чем с системдой. К счастью именно поэтому с ним в жизни встретиться - не придется.
> но так редко делают.
В системд если ОЧЕНЬ надо - можно в ExecStart(Pre, Post) и шелскрипт запустить. Но поскольку это выглядит как костыль - вот там ЭТО и правда редко, когда реально - надо. И оговорен и-фейс между sd и допустим Pre, так что если пречек конфига или подготовка арены хелпером не удалась - оно заметит, и отмаркирует как FAILED сразу. А как с этим дела у вон тех? Как обычно - косплеят в режиме "почти Харлей, только китайский и из дешевого вонючего пластика"?
читать учимся, госпадин.
>когда еще sd был сервисным менеджероми рассматриваем все в этой парадигме.
резать операции Вашим сервисам - задача MACa/контейнеров.
стартовать контейнер - задача сервисного менеджера.
Вам явно в призму ткнули в сообщении - можете эту тираду про "доступ в шелл" можете сунуть обратно в карман.
хотя, именно касаемо отношения системы разганичений привелегий к серв. менеджеру я не уверена. в openrc подобному мешает только большая разница в реализации ядра этого механизма на разных платформах.>Он как был кучей костылей и подпорок, решающий фиг знает какие задачи/проблемы, и почему именно так - таковым навечно и останется.
давайте список ?
и костылей, и подпорок.
2 года в openrc багфиксы отправляла, писала политику tomoyo под все компоненты оного.
поэтому могу разьяснить вот буквально по каждому файлу, что в поставке идет.
а еще писала политику tomoyo под современную систему с sd .. так что, выкладывайте карты, давайте сравним )>1) Нормальный обзор статуса системы. Я 1 утилитой могу глянуть ок ли моя система. Есть ли сбоящие сервисы. Вот это все. А еще парой - время старта и анализ кто систему клинил.
а я, говоря, что openrc функционалу сервисной части sd не уступает, не голословила.
rc-status.
и тоже будет статус по всем сервисам, с к.-вом рестартов, временами падения, временами работы и др. логов, разве что, именно эта команда не выведет.
тем не менее, openrc все будет логировать, куда Вы ему скажете. по умолчанию все в /dev/log идет. и Вы просто смотрите в своем демоне логирования лог, где в качестве источника указано имя сервиса openrc. например, так:
sudo logread -u polkitd
>Нормальный логгинг, когда2б) если сервис не взлетел то коды возврата, сообщения stdout/stderr и проч в логах
Вы не поверите !
openrc делает вот ровно то же самое, от имени supervise-daemon с меткой сервиса.
касаемо логротейта - так поставьте себе нормальную реализацию сислога. у меня на роутере, напр., давно логи в sqlite.
и я просто делаю logread -u serviceName, чтобы посмотреть, почему у меня сервис упал.>3) Тулинг для типовых задач. Хочется рулить контейнеры или виртуали?
идете и ставите себе контейнер.
про это я в самом начале написала.
с тем же успехом можно во все дистрибутивы по дефолту прям весь софт на свете пихать. и всех версий обязательно.
чтоб исошники под миллиарды ТБ были. вдруг юзеру захочется !!>Включает в себя трек успеха загрузки и информирование бутлоадера, реакцию на сбои сервисов, работу с аппаратным вачдогом и проверку что сервисы которых оно супервизит реально живы, а не плймали локап неделю назад при всеобщем пофиге на все и вся, как вон там.
по порядку ..
openrc реагирует на падение сервисов, как Вы ему скажете в конфиге.
openrc инициализирует вотчдог.
openrc давно не использует pid-основанную систему контроля состояния. поэтому да, там сервисы "реально живы".
касаемо бутлодера - это Вы приврали.
boot counting сейчас не работает из коробки НИГДЕ. вот буквально.
даже в дистрах, где загрузка через sd-boot.
ибо он требует настройки.
более того, он требует загрузки ИМЕННО через sd-boot. Вы даже загрузившись с UKI, ничего не получите.
много там эмбедщины на sd-boot ? :)>Да, системный менеджер это не только про запуск. Это еще про "супервайзинг" системного "здоровья" и того что запущено.
учимся, говорю, читать, увОжаемый.
"сервисный" != "системный".
за сервисами openrc следит.
а 90% компонентов для системного менеджмента sd, в крупных дистрибутивах(и нет, речь не о Вашей федоре на десктопе. а о rhel, ubuntu и debian. про эмбедщины вообще молчу - там часто alpine либо что-то кастомное) не используются по дефолту.>Лично я очень рад что забыл про init.d как страшный сон. И теперь у меня нормальное управление системой а не пародия из спичек и желудей, "зато свое!".
0 по делу, словестный мусор.
>На мой вкус я не буду скучать о совместимости с тем мусором из 70-х. Зачем в авто оглобли для запрягания лошадей?!
грамматика уровня 4го класса; странная аналогия, не применимая к сфере ПО; непонимания основ проектирования ПО в целом.
мда.>Что обрекает тех кто будет эти системы майнтайнить, если это не локалхост, на неприятные сюрпризы. Чаще чем с системдой. К счастью именно поэтому с ним в жизни встретиться - не придется.
к счастью, это 99% контейнеров, некоторое к.-во встраиваемых систем и внушительное к.-во серверов.
google://alpine linuxи да.. это ничем не отличается от рандомного бинаря или шелл-кода в Exec, в случае с systemd.
полностью супервизию сервиса со стороны openrc это не отключит.>В системд если ОЧЕНЬ надо - можно в ExecStart(Pre, Post) и шелскрипт запустить.
вот не поверите - в openrc также.
и способы с бинарями в init.d и шелл-скриптами явно помечены, как нерекоммендуемые, в документации. и так никто не делает.
но зачем Вам вникать-то в матчасть, когда можно повторить список странных и давно избитых аргументов.
> читать учимся, госпадин.
>>когда еще sd был сервисным менеджеромВ нем с САМОГО НАЧАЛА были замашки на
1) Нормальный логгинг без более 9000 проблем предшественников. Еще и tamper proof, братец Лени целый тезис задвинул, тот не долго думая заимплементил это в journald.
2) Интеграция с пакетниками. С четкими регламентами где дефолты, где оверрайды админа.
3) Обзор и диагностирумеость. Буквально 2 приблуды (systemctl и journalctl) показывают ключевые аспекты сервисов в системе и логинг.А те в пролете как раз потому что вместо этого из достоинств - "более быстрые лошади". Сапопикал уже пробовал это. И тут их обошли на повороте.
> и рассматриваем все в этой парадигме.
ИМХО мир лучше всего рассматривать - таким какой он есть. Системд с самного начала был амбициознее и перспективнее. Это многим нравится. Совместимость с д@рьмом из 70-х прошлого века сомнительное достоинство. "Отборный овес, свежая вода в корытах"? Удачи бензоколонке с таким позиционированием.
> резать операции Вашим сервисам - задача MACa/
Их настраивать канительно - за что и выпали из фавора. Предпочитаю чтбы в защитах надолго увязали - атакующие, а не админы.
> контейнеров.
1) Прелесть системды в том что он это и делает несколькими директивами.
2) Это все равно откуда-то запускаться должно.
3) настраивать это где-то еще - не логично.> стартовать контейнер - задача сервисного менеджера.
Зачем мне конфигурация 1 действа в 2 местах? Это очень не практично. И это 1 из основных претензий юниксвею.
> Вам явно в призму ткнули в сообщении - можете эту тираду про
> "доступ в шелл" можете сунуть обратно в карман.Потому что вам нечем крыть с тем лоскутным одеялом? :)
> хотя, именно касаемо отношения системы разганичений привелегий к серв. менеджеру я не
> уверена. в openrc подобному мешает только большая разница в реализации ядра
> этого механизма на разных платформах.1) Линух я юзаю не для того чтобы получать фичесет какой-нибудь нетбсд или чего там.
2) Думаю что мешает еще и тот факт что при радикальной изоляции утилитки и баш - останутся "где-то там". Изолируемому сервису их вызывать как раз - не надлежит. Иначе не такой уж он и изолированный.> давайте список ?
> и костылей, и подпорок.Вы сами за меня это сделали. Рассказами про совместимость. Почему меня в 2025 году совместимость с барахлом из 1970х вообще должна колыхать? Я не вижу причин скучать по runlevel'ам и прочему антикваирату.
Не, systemd не оперирует внутри таким бредом. У него есть "target" - это намного более мощный superset идеи. И его логгинг мне куда как. И systemd.timers - намного логичнее крона. И главное смотрятся 1 утилиткой оптом. Как обзор системы.
> 2 года в openrc багфиксы отправляла, писала политику tomoyo под все компоненты оного.
> поэтому могу разьяснить вот буквально по каждому файлу, что в поставке идет.Мне на уровне концепций ваши более быстрые лошади и совместимость с окаменелым барахлом из прошлого века ценой нормального системного менеджмента - не ок. А вот это вам - не завозили.
И я могу себе представить сколько вы времени убили на настройку tomoyo. Именно поэтому я буду достигать сравнимых целей в цать раз быстрее, контейнерами вообще и системдой в частности, а то и VM где суровее изоляция нужна. У системды и для этого есть полезные утилсы, machniectl тот же. А в этом вашем openrc - более быстрые лошали.
> а еще писала политику tomoyo под современную систему с sd .. так
> что, выкладывайте карты, давайте сравним )А какого характера карты вы хотите? Ну вот например... в случае s-d я могу посомтреть дельту относительно дефолтов дистра 1-2 командами. Как относится к безопасности? Элементарно: я могу быстро понять на что обратить внимание в первую очередь. Какие тут кастомные сервисы, какие параметры сервисов сменили.
Или во:
...
[Service]
User=someprog
Group=someprog
Restart=always
RestartSec=5
# Hardening
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=strict
ProtectControlGroups=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictNamespaces=yes
LockPersonality=yes
ReadOnlyPaths=/run
RuntimeDirectory=run
NoNewPrivileges=yes
...
Смена юзера не самое интересное. Интереснее что они получают "лысую" ФС, в которой минимальный /dev и бесполезный /home, зарубается возможность менять системное файло, операции с модулями и tunables ядра, никаких новых привилегий, форсированный W^X и все такое прочее, типа запрета реалтайм шедулеров (зачем они обычной проге?).А как вы все это сдалеате с вашими парадигмами и сколько это займет? Это копипаст из стандартной болванки, на самом деле можно еще подзакрутить - man systemd.exec и там все что Restrict/Protect. Скажем SystemCallFilter=<список разрешенных сисколов>. С пресетами даже. Или NoExecPaths=/ (тогда сервис вообще не сможет запускать программы из фс).
Для важных штук можно OOMScoreAdjust=<something>. Чтоб их не прибило по ерунде. Там же и вещи типа affinity на энный проц, если надо. Или например IO scheduling. Не про безопасность, но рядом - стабильность системы. Если сервис может дико жрать проц с реалтайм шедулингом, остальное сможет почти-умереть икая адскими таймаутами на все вообще.
> а я, говоря, что openrc функционалу сервисной части sd не уступает, не
> голословила.
> rc-status.
> и тоже будет статус по всем сервисам, с к.-вом рестартов, временами падения,
> временами работы и др. логов, разве что, именно эта команда не выведет.Может там еще и показ всей "периодики" и "активации через сокет" будет? Чтобы знать кто откуда лезет - по настоящему? Или даже аналог systemd-delta найдется? Ибо первое что меня интересует на "вон той машине" - а чем это отличается от дефолтов дистро, которые я более-менее знаю?
> тем не менее, openrc все будет логировать, куда Вы ему скажете. по
> умолчанию все в /dev/log идет. и Вы просто смотрите в своем
> демоне логирования лог, где в качестве источника указано имя сервиса openrc.Я рад за него. А s-d таки указывает в качестве источника - то что реально источником было. Если он сам - себя, если сервис - сервиса. На самом деле настраиваемо.
И я рад что у s-d есть свой демон логирования - который сразу нормально работает. Т.е. не выжрет все место при runaway какого-то флудера, и не надо logrotate каждой фигне лично тыкать, вместо этого нарулив общесистемную политику сколько какому журналу можно максимум жрать.
> openrc делает вот ровно то же самое, от имени supervise-daemon с меткой сервиса.
К сожалению, если кто будет вот тут размахивать совместимостью с огромными простынками sysv - там с этим полный швах. А меня с практической точки зрения волнует - чтобы у меня таких подарков не было.
Нет ничего более деморализуюшего чем когда запустил стартовый скрипт под рутом, все сработало ок, но при рестарте сервака/вм/чего там - опа. Тишина. Угадай что не так. И тут вы таеие говорите что совместимость с этим Г фича. Ага. Щас. Это не фича, это лишний раз получить вон той граблей в лоб. То что это проще (и значит будет случаться чаще) - никак не фича.
> касаемо логротейта - так поставьте себе нормальную реализацию сислога. у меня на
> роутере, напр., давно логи в sqlite.Вот системд это и делает - предоставляя нормальное штатное решение для этого. А кому надо нечто этакое заменит journald на что он там хотел, или дополнит. И тоже сможет в скулайт или куда там складировать. Если это надо. Меня и journald устраивает в общем случае.
А еще s-d умеет рюхать coredumps по дефолту, так что они и как бы есть, но и как бы неконтролируемое место и вечно - в проде не сожрут. Удобно и прагматично. Конечно в идеале падать не должно, но раз в год и палка стреляет.
> и я просто делаю logread -u serviceName, чтобы посмотреть, почему у меня
> сервис упал.А я смотрю systemctl status <SERVICE> первым делом. Упал он там или что еще - вопрос номер два.
И между нами - я только что закатал шикарный комит с фиксом нестартуюшего в проде сервиса благодаря тому что sd заметил что сервис наворачиваеится при старте и собрал мне coredump в характерную локацию. Откуда я его взял, подивился что оно раз в год о как умеет - да и навесил фикс.
>>3) Тулинг для типовых задач. Хочется рулить контейнеры или виртуали?
> идете и ставите себе контейнер.
> про это я в самом начале написала.Агаблин. И получаю еще в цать раз больше оверинженерии и конфиги в разных местах. А это точно EPIC WIN?
Знаете, если ваш тул заставляет вас хватать энтерпрайзные логгеры, управляторы и проч даже для неэнтерпрайзных задач - может, не такой уж тул и хороший?
> с тем же успехом можно во все дистрибутивы по дефолту прям весь
> софт на свете пихать. и всех версий обязательно.Как минимум в репы - его и пихают. А так размер системды - по сравнению с размером списка пакетов моего дистра - просто не заметен. Дебиан его на субпакеты нарезал. И кстати он не есть жесткий depends минимального дебиан. На минималках debian бутстрапается и совсем без init. Но это малость неудобно :)
> чтоб исошники под миллиарды ТБ были. вдруг юзеру захочется !!
У дебиана исошки можно скачать воооон там. Не знаю, нарезает ли их кто в таком количестве, но так можно было. Мне проще - делать миррор репы на вооон тот терабайтник. Так тоже можно было.
>>Включает в себя трек успеха загрузки и информирование бутлоадера, реакцию на сбои сервисов, работу с аппаратным вачдогом и проверку что сервисы которых оно супервизит реально живы, а не плймали локап неделю назад при всеобщем пофиге на все и вся, как вон там.
> по порядку ..
> openrc реагирует на падение сервисов, как Вы ему скажете в конфиге.И что ему можно сказать? В системд можно при failure энного юнита - запустить вон тот юнит. Как этакий "exception handler" фэйла (ре)старта критичного юнита.
> openrc инициализирует вотчдог.
И дальше что? Вот есть у меня сервис. Он через полчаса работы - повис. Или он стартовал, стартовал, и задумался навечно, не закончив старт. Как об этом openrc узнает?
> "реально живы".
Как это нечто узнает что сервис - живой? Вон тот видите ли может и через апи нотификаций видеть что процесс реально в состоянии подать признаки жизни. А самого вачдогователя мониторит хардварный или хотя-бы ядерный вачдог.
> касаемо бутлодера - это Вы приврали.
> boot counting сейчас не работает из коробки НИГДЕ. вот буквально.Тем не менее в системд есть готовые facilities для этого. И у GRUB обвес для этого.
> много там эмбедщины на sd-boot ? :)
sd-boot вообще ортогонален boot counting и uki как таковым, ВНЕЗАПНО. Так что я не понял этот реверанс.
> учимся, говорю, читать, увОжаемый.
> "сервисный" != "системный".Это пересекающиеся множества. Скажем startup или shutdown - не сервиса, а системы вообще. А рюхается - вот этим софтом опять же.
> за сервисами openrc следит.
> а 90% компонентов для системного менеджмента sd, в крупных дистрибутивах(и нет, речь
> не о Вашей федоре на десктопе. а о rhel, ubuntu и debian.Чего там в моем дебиане - нет? Там майнтайенеры не только tor сделали с инстансами (openrc кстати умеет инстанциируемые сервисы?) так что можно запустить 5 вариантов тора с разными конфигами одной левой, а при желании перманентно заоверловадив кому-то из - и изменяния юнитов системды, но и урезали ему привилегии и доступы сразу по дефолту.
А с openrc кто вообще что-то стравнимое вообще делает чтобы сервис out of the box был порезан на манер примера выше - сразу опосля инсталла?
> про эмбедщины вообще молчу - там часто alpine либо что-то
> кастомное) не используются по дефолту.Ни разу не видел alpine в эмбедщине. И лично я это практикую, с дебианом обычным. Неплохо катит. Альпин это вообще головняка кусок! С их musl и его загонами на тему мелкого размера стека по дефолту. Половина софта - особенно кастомного - там зачастую тупо ПАДАЕТ. И при том не всегда - сразу. Что как бы подстава. Но если хочется помучаться и поавралить, отличный выбор.
> грамматика уровня 4го класса; странная аналогия, не применимая к сфере ПО; непонимания
> основ проектирования ПО в целом. мда.Вы пока ни 1 user visible достоинства вашего openrc относительно s-d не привели. Только какие-то подгоны решения под ответ.
Но мне нет никагого смысла обманывать себя. Будем честны. Правильный way имхо - тот который упрощает мою жизню и делает то чем я занимаюсь быстрее и эффективнее.
> к счастью, это 99% контейнеров, некоторое к.-во встраиваемых систем и внушительное к.-во
> серверов.
> google://alpine linuxБезблагодатная набивка для энтерпрайзных контейнеров. Больше нигде не встречается. Ибо грабель кусок с их musl. И кроме как для запуска CI которые никто не видит - нафиг не вперся никому.
> полностью супервизию сервиса со стороны openrc это не отключит.
Он умеет в эту фактическую сурпервизию, для начала? С вот реально чеком живости сервиса через какое-нибудь апи взаимодействия?
>>В системд если ОЧЕНЬ надо - можно в ExecStart(Pre, Post) и шелскрипт запустить.
> вот не поверите - в openrc также.Ну я поздравляю, дошло.
> и способы с бинарями в init.d и шелл-скриптами явно помечены, как нерекоммендуемые,
А зачем тогда вы педалировали это как достоинство? Чтобы оказать своему объекту обожания медвежью услугу? Это получилось, поздравляю. Ибо ни 1 достоинства относительно sd я не увидел, а вот недостатков - есть.
> в документации. и так никто не делает.
> но зачем Вам вникать-то в матчасть, когда можно повторить список странных и
> давно избитых аргументов.А еще ... на всех серверах с которыми я имею дело были дебианы и убунты. И там системд. При том дебиан достаточно универсален чтобы быть и на моем десктопе, и на вон тех vm, и в вон тех контейнерах, и вон тех одноплатниках. Ну или убунта - на серверах которые не лично мои но в проектах которые мне не пофиг и где я вписался. И мне удобно ворочать выводками ОДНОЙ технологии. А вы можете колупаться с вашим альпином. Но я посмотрю как вы ЭТО себе на десктоп поставите. Или вгрузите 3-4 копии разных знаний делания одного и того же.
И вот тут мы посмотрим кто кого сделает. Я более менее углубленно знающий "свои" технологии или вы с метанием между альпинами и чем там? Если что для меня вон то - побочное тезническое зло. А реальные цели и задачи - вовсе не администрирование систем. Я это умею потому что для одноплатников косплею нечто типа OEM Lite да и самообслуживание в опенсорсе в моде. Как special perk я вон тем VM нагенерил под специфичную проблематику.
Таки то что sd в майнстримовых дистрах повышает ценность этого знания.
Да, печально как то все у вас ребята с этим менеджером сервисов/системы. Вот у меня все проще - даже если винда вместо 2 секунд загружается целых 3 секунды, я вообще не парюсь, не смотрю, что там за сервис "застрял" при запуске, ибо понимаю, что лучшее - враг хорошего. Куда вы все так спешите, какая разница ну грузится системы на пару секунд дольше, что такого.
> Да, печально как то все у вас ребята с этим менеджером сервисов/системы.
> Вот у меня все проще - даже если винда вместо 2
> секунд загружается целых 3 секунды, я вообще не парюсь, не смотрю,Спасибо, я в курсе что такое SCM. И очень хорошо, что все это - не у меня!
Господи, там просто пнуть произвольную прогу или скриптик без спецэффектов и приключений - это капец какой-то. Потому что изначально сервисы - это вообще специфичные DLLки! До такого решения допереть мог - вот реально только майкрософт. А потом - как и реестр - осталось на память о временах с тормозным FAT и древней виндой.
И, конечно, в реестре не будет никаких коментов что этот параметр на 100500 странице тут делает. А рихтовать параметры SCM в регэдите - ну такое себе удовольствие. А в "services.msc" - гопсоди, а этот крап хотя-бы удалить совсем не нужный мне сервис - может? А, не, надо вот именно в суперудобном регэдите какой-нибудь вот именно СВОЙ сервис выпиливать? Или вообще сетапер кодить? Очень удобно и результативно, особенно для разовой фигни.
> что там за сервис "застрял" при запуске, ибо понимаю, что лучшее
> - враг хорошего. Куда вы все так спешите, какая разница ну
> грузится системы на пару секунд дольше, что такого.Только в итоге - винда враждебна к автоматизации и продвинутому использованию теми кто о своей эффективности парится. И вы врядли сделаете из винды допустим эмбедовку нормально, делая self-recovery пока возможно, или failsafe, если нет. Из винды не получится ни то, ни другое, да и вообще кастомизировать ее - мучение. Операционка для домохозяек и есть операционка для домохозяек. Более развитым существам не очень подходит.
> Линусу было нас рать, а вот Лёня мог улучшить openrc, а не
> городить своё.Очень хорошо что он вместо потуг сделать более быстрых лошадей которых вы просили - запилил нам нормальные комфортные автомобили и конвейер для их производства. Разница примерно такая же. А вы можете сидеть в конюшне и чистить любимого рысака дальше.
Так автомобиль - svchost.exe. А это китайская копия неизвестной сборки. Кому надо автомобить, тот перейдёт на винду.
> Так автомобиль - svchost.exe. А это китайская копия неизвестной сборки.Не, судя по фичесету и тому как это работает - все выглядит ровно наоборот. Svchost это кривая шляпа, с совершенно левым управлением и 10% от возможностей системды. Достаточно сказать что MS зачем-то сделал сервисы - DLL'ками. Этот бред унаследован чуть ли не с времен винды 3.11.
А запустить произвольную произвольную программу в винде как сервис - это вообще какое-то совершенно левое мучение. Так по жизни. Кривая конструкция набитая легаси эпохи маздая 3.11.
> Кому надо автомобить, тот перейдёт на винду.
Пока, вроде, обратный тренд, аж WSL кой-кто запилил. Вон те попробовали - запрячь вместо лошадей трактор в карету. Не то чтобы это совсем не работало... но...
Походу Вам не надо ехать, Вам надо шашечек. Но это Вашем мнение и я его уважаю! Не понимаю, но уважаю!
> Походу Вам не надо ехать, Вам надо шашечек. Но это Вашем мнение
> и я его уважаю! Не понимаю, но уважаю!Я езжу получше вашего, тем более на эмбедовке какой. Под которую винды вообще причесать в виде как это должно быть на самом деле - почти mission impossible. В силу характерной кастомизируемости винды.
в каких дистрах этот s6 по дефолту? как попробовать это чудо?
Artix делают ISO-шки с разными init системами, в том числе с S6.
В Artix не по дефолту но есть сборки почти со всеми альтенативными инитами.
А чего это анализ зависимостей ресурсоёмкий?
кубическая зависимость от количества сервисов.
> bcnm 0.0.2.0 - сетевой конфигуратор с возможностями для настройки Wi-Fi на стороне клиента.Глючный Wicd и безфичевый интеловский iwd теперь можно закопать.
Толсто.
Какое-то дикое подобие ненужнодэ,таким каким его видят программисты. Ну, может и пригодится кому, но runit как Калашников - простой и надежный. В ненужнодэ и так уже задомонировать над системой пытаются изо всех сил. Достали маньяки, которые пытаются все контроллировать со своими комплексами.
помню в CRUX'е решил инит заменить, не осилил s6, я так понял все скрипты там предполагается писать на execline с нуля... runit за час поднял и все прекрасно работало. s6 вроде в alpine хотели вкорячить, забросили?