В OpenRC добавлены пользовательские сервисы

Too little too late. Но хорошо что появилось.

Благая весть!

Отлично. Может быть переползу когда-нибудь с runit.

А зачем вы себя так мучаете все?

openrc-run: Disable cgroups for user services due to lack of permissions

LMAO. Ну вот как так-то. Если я правильно помню, у dinit такой проблемы нет. OpenRC все-таки не вывозит в 2025.

а чем ты предлагаешь пользоваться вместо?

systemd или dinit. все остальное уже subpar

https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

Although the build system seems to have some support for BSD OSes, it did not build successfully on OpenBSD when tested (revision 33d3f33)

ну ладно, я и не собирался запускать его под OpenBSD :)

Кажется никто никогда не собирался, это безумие.

OpenRC – система инициализации для Linux-систем

Для UNIX-like систем. Как минимум в GhostBSD, форке FreeBSD, используется OpenRC в качестве системы инициализации.

которая поставляется вместо systemd в таких дистрибутивах как Gentoo и Alpine Linux.

И, пожалуй, всё. (=

Опоздали лет на пятнадцать, но новость всё равно хорошая. (=

У runit один недостаток: он стартует сразу все сервисы с перезапуском в надежде что рано или поздно оно запустится.

Я дважды пытался использовать его на ноуте с FreeBSD, но runit творит дичь на старте, засирает логи (и сеть, если включен remote syslog) и… в принципе с задачей справляется. Тупо, топорно, но эффективно… почти. (= Если нужна строгая последовательность — прописывай ручками старт/стоп зависимостей в скрипте, а если с этими же зависимостями работают другие сервисы… ух, забористые вещества они там курили! (%

Иех, я опять на стороне проигравших... Меня ещё на первой войне инитов контузило, между бсд инит и систем пять. Топил за бзд, оборонял слакварь, как последний форпост. Потом по лесам бродил и прибился к лагерю ОпенРЦ. Но и эта война похоже проиграна.

И, пожалуй, всё. (=

Ещё Devuan и Artix, как минимум.

которая поставляется вместо systemd в таких дистрибутивах как Gentoo и Alpine Linux.

И, пожалуй, всё. (=

А больше и не надо. Остальные пусть на убунте сидят

Из классических инитов мы сейчас имеем только OpenRC и BSD init в разных вариациях (потому что они уже давно не идентичны в существующих *BSD). Всё.

• OpenRC выигрывает у BSD init наличием распараллеливания. Во FreeBSD rcorder(8) умеет генерировать список инит-скриптов для параллельного запуска, только это нигде не используется.
• BSD init выигрывает у OpenRC монументальной стабильностью благодаря обкатанной десятилетиями шелл-портянке /etc/rc.

У runit, daemontools, s6 и прочих маргиналов подход сильно отличается, и назвать их классическими нельзя. По сути это вообще супервайзеры, которые правильнее использовать вместе с инитом, а не вместо.

systemd вообще нагло с-3.14-здили идею у launchd(8) из macOS. Использовать DOS INI (вместо маковской надстройки над XML) для декларации сервиса было мудро, но пихать в инит решительно всё — идиотизм. Do one thing and do it well!

Ну это уже конкретные маргиналы, целью которых изначально была борьба с systemd. (=

Это всё хорошо, но совершенно бесполезно: смузихлёбам[1] нассать что там как работает, оно должно быть модным-молодёжным и релизиться каждый час, а прошлогоднее говно мамонта можете закопать!

[1]: Далеко ходить не надо, примеры в этом треде:

• В OpenRC добавлены пользовательские сервисы (комментарий)
• В OpenRC добавлены пользовательские сервисы (комментарий)
• В OpenRC добавлены пользовательские сервисы (комментарий)

вместо systemd

И, кстати, не вместо. Никогда там не было systemd, его не заменяли.

Кстати, я застал арчик на сабже. (=

Конфигурационные файлы и скрипты инициализации пользовательских сервисов размещаются в следующих папках:

Чем не угодила папка «/etc/local.d»?

В OpenRC добавлены пользовательские сервисы

А как без них справлялись?

Редакция данной новости как пользовалась s6 для запуска всяких syncthing, так и планирует продолжать это делать, потому что «все работает» (тм). Кроме того, часть сервисов вроде mako и xdg-desktop-portal умеет запускаться автоматически с помощью dbus-активации, а всякие wireplumber можно настроить на запуск через пайпварь.

Отдельная головная боль - это gnupg, которые выпилили у себя возможность запускаться под супервизором и рекомендуют gpg-connect-agent, который может в любой момент времени вывалить окно с pinentry и превратиться в тыкву, если к тому моменту гуй ещё не поднят. Ищу, чем бы заменить его. Пока вариантов не дофига.

Как всё? А Диван? (Devuan)

там системд так и не выкосили полностью, не прибрано, скверна

Его щупальца уже даже в Gentoo просачиваются, к сожалению.

Та не забористые, просто сделали простую как тапок систему сервисов. Кстати, где почитать про «ручками старт/стоп зависимостей в скрипте»? Я как-то пытался, но так и не нашел вменяемых гайдов. И что посоветуешь в качестве замены? OpenRC хорош в этом плане?

так в диване луддиты. Орут «сустемд плохо», сами при этом ничего не разрабатывают и только тащат к себе всякую тухлятину. За чистотой архитектуры - точно не к ним.

Бгы.. на сколько они от systemd отстают получается? Лет на 10? Или уже больше?

Но и эта война похоже проиграна.

Проклятущие разрабы опять не хотят бесплfтно реализовывать твои хотелки? :-D

Можно ли будет их использовать не заменяя основной инит?

А как без них справлялись?

Как обычно - говорили «не нужно» до тех пор пока наконец-то не осилили скопировать очередную фичу из systemd.

простую как тапок систему сервисов

так и не нашел вменяемых гайдов

Тебя правда ничего не смущает?

системд и чмстота системы это разные вещи. я разрабатываю и на отлично знаю какая это помойка с костылями.

я разрабатываю и на отлично знаю какая это помойка с костылями.

Ни секунды не сомневался что ты исключительно помойку с костылями можешь разработать.

Я как-то пытался, но так и не нашел вменяемых гайдов.

Где-то в дебрях документации Void Linux видел, кажется… Или у кого-то в блоге. Это было года четыре назад, я уже не помню.

И что посоветуешь в качестве замены?

Я ни за кого не агитирую. Мне и runit в Void был норм, и systemd в Debian на виртуалке сейчас, и OpenRC вспомню, если столкнусь снова, и BSD init во FreeBSD не так уж плох, если разобраться как он работает (забавный факт: в данный момент изобретаю обход логики /etc/rc, не модифицируя его).

Если тебя чем-то не устраивает твой текущий инит, при этом ты пытался с этим бороться и не справился — тогда стоит взглянуть на альтернативы, в противном случае, if it ain’t broke, don’t fix it.

OpenRC хорош в этом плане?

Это просто классический инит. Со своими преимуществами и недостатками. В нём тоже есть супервайзер (в SysV и BSD инитах супервайзинга искаропки нет, но это легко решаемо), но он использует классическую схему управления инит-скриптами.

OpenRC… не помню как оно там называется, во FreeBSD это rcorder(8)… генерирует граф зависимостей и запускает инит-скрипты последовательно друг за другом, если включена параллелизация, запускает параллельно те, зависимости которых уже running. В systemd используется что-то похожее, но чуть более хитрое.

Можно ли будет их использовать не заменяя основной инит?

Если ты сможешь запустить инит от юзера (звучит бредово, знаю ☺), то скорее всего да.

Это он? systemd-капец или еще нет?

А что это за сервисы-то? Пример можно? И собственно, как без них раньше жили во времена оны (систем файв тобишь)?

А где я неправ? Вместо рабочего мейнстримного решения с нормальными фичами люди пердолятся с runit, который даже порядок загрузки не умеет. И чтобы что? СмОтРи МаМа Я ХаКиР?

А что это за сервисы-то? Пример можно?

Любые сервисы, которые нужно запускать в рамках пользовательской сессии. То же получение почты например.

И собственно, как без них раньше жили во времена оны (систем файв тобишь)?

Хреново разумеется - с помощью костылей и лапши на баше.

рабочего

Где это OpenRC не рабочий?

мейнстримного

Миллионы мух не могут ошибаться, да? (%

с нормальными фичами

Каких функций ИНИТА не хватает в OpenRC?

люди пердолятся с runit

Ну, свою задачу он выполняет. Через жопу, но выполняет. (%

И чтобы что?

А зачем вообще что-то менять? Вот поставил юзер, например, Void Linux, там искаропки runit, ты предлагаешь пердолиться и валить на systemd? Или свалить на дистр с systemd и пердолиться с чем-то другим, что устроено не так как в Void? (%

А можно еще раз напомнить, зачем оно вообще сейчас существует?

Вот поставил юзер, например, Void Linux

А, ясно, нетакусики.

На вопросы отвечать будешь, кловун?

А, ясно, ты же ничего кроме своей дегенератской мантры не знаешь.

Ответ на самом деле один: это все никому не нужно, поэтому оно не тестируется и не разрабатывается. OpenRC не может даже нормально залогировать ошибки сервиса в stderr. Это надо руками делать лол. Ротацию логов руками делать. Нет простого способа сделать зависимость сервиса от точки монтирования. Нет таймеров.

Я знаю что люди почему-то тревожатся когда логирует тот же набор утилит, что и стартует… но ведь runit делает так же, лол.

То же получение почты например.

пользователи системГ кроном пользоваться никогда не умели, понятно.

никому не нужно

никому

Ты опрос проводил? Где результаты?

не разрабатывается

Ну да, конечно, если оно не высирает новый релиз раз в час, то ОНО СДОХЛО, ЗАКОПАЙТЕ!!!11 (%

OpenRC не может даже нормально залогировать ошибки сервиса в stderr. Это надо руками делать лол.

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

Нет простого способа сделать зависимость сервиса от точки монтирования.

Потому что точки монтирования это не задача инита. Да, он монтирует fstab на ранних этапах, и всё. Если что-то монтируется не из fstab, значит админ (а не инит!) должен обеспечить сервис, которым это отслеживается.

Ротацию логов руками делать.

Нет таймеров.

А это вообще не задачи инита.

Ты опрос проводил? Где результаты?

Давай без кокетства, void это очень, очень нишевый дистрибутив.

Ну да, конечно, если оно не высирает новый релиз раз в час, то ОНО СДОХЛО, ЗАКОПАЙТЕ!!!11 (%

Я этого не говорил. Сам придумал, сам оскорбился.

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

Что за бред? Если stdout/stderr дошел до консоли, он уже нигде не используется. Это банально наследие unix, когда логировали либо сами, либо в syslog, либо никак. systemd решил это журналом, s6 и runit решил это логером, openrc не решил это никак, надо руками писать везде stdout_logger=“logger …”.

Потому что точки монтирования это не задача инита. Да, он монтирует fstab на ранних этапах, и всё. Если что-то монтируется не из fstab, значит админ (а не инит!) должен обеспечить сервис, которым это отслеживается.

Кто сказал что не задача менеджера сервисов? Деды в 80х? Насрать на них. Я не хочу чтобы база запускалась, если ее /var/lib/postgres не смонтирован.

А это вообще не задачи инита.

Ни openrc ни runit это не иниты, это менеджеры сервисов. Все это там должно быть.

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

Есть systemd: добавил override с одной строкой, все хорошо. Есть bash-портянка: написал что-то руками, теперь не применяются апдейты из пакета, потому что пакетный менеджер видит что файл сервиса изменен.

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

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