LINUX.ORG.RU

Пользовательские сервисы OpenRC: инструкция по применению

 , , ,


5

3

Как я уже писал раньше, в систему инициализации OpenRC недавно добавлена возможность запускать сервисы в пользовательской сессии. В этой статье я покажу, как этим пользоваться, на примере pipewire в Alpine Linux.

Что было раньше

Раньше в пакете с pipewire поставлялся (и до сих пор поставляется) скрипт /usr/libexec/pipewire-launcher, который предлагалось прописывать в конфиге sway. Особенность этого сетапа в том, что после остановки Sway все запущенные им в background процессы оставались висеть в памяти, и перед последующим запуском их предлагалось прибивать с помощью pkill. Не говоря уже про полное отсутствие логов, их не было.

Чтобы решить эти проблемы, нужно запускать pipewire в пользовательской сессии под супервизором. Собственно я так и делал при помощи s6, однако добавление пользовательских сервисов в OpenRC, а также соответствующих конфигов в пакеты в репозиториях Alpine позволяет отказаться от этих скриптов и пользоваться тем, что поддерживают мейнтейнеры дистрибутива.

Версии

Пользовательские сервисы были добавлены в OpenRC 0.60. Версия в репозиториях Alpine Edge на данный момент - 0.60.1. Используется pipewire 1.4.1 и wireplumber 0.5.8.

Зависимости

Для поддержки пользовательских сервисов нужно установить пакет openrc-user. Он содержит необходимые исполняемые файлы (openrc-user и openrc-user-pam), а также PAM-модуль pam_openrc.so.

PAM

Есть два способа запуска пользовательской сессии OpenRC: как сервис

$ doas rc-service user.${USER} start

и через PAM.

Предпочтительным является второй способ. Для того чтобы им воспользоваться, нужно подключить соответствующий PAM-модуль стандартным способом:

$ cat /etc/pam.d/base-session 
# ...
-session optional pam_rundir.so
session optional pam_openrc.so

Если $XDG_RUNTIME_DIR не создается автоматически, то нужно об этом позаботиться. Для этого я применяю еще один модуль pam-rundir (есть в репозиториях).

Перезагружаемся и проверяем, что пользовательская сессия работает:

$ rc-status --user

После этого можно запускать сервисы.

Запуск сервиса

В репозитории Alpine Linux уже начали добавлять файлы конфигурации пользовательских сервисов для разных пакетов, поэтому руками ничего писать не надо (если вы конечно не хотите запилить что-то свое кастомное):

$ rc-update --user add dbus default

Эта команда заставляет dbus автоматически запускаться при старте пользовательской сессии, являясь аналогом systemctl --user enable dbus. Симлинки на включенные сервисы располагаются в папке ~/.config/rc/runlevels, а сами конфиги лежат в /etc/user/init.d и /etc/user/conf.d.

Переменные окружения

DBus относится к типу сервисов, которые должны устанавливать особую переменную окружения, в данном случае $DBUS_SESSION_BUS_ADDRESS, для всех кто от них зависит. К таким зависящим относятся пользовательские сервисы и Sway. Раньше был только Sway, и подобная зависимость легко решалась тем что он запускался как потомок dbus-run-session:

cat /usr/share/wayland-sessions/sway.desktop | grep dbus
Exec=dbus-run-session /usr/bin/sway

Однако сейчас такой фокус не пройдет, потому что пользовательские сервисы запускаются независимо от Sway. И больше того, в OpenRC пока нет механизма, позволяющего сервисам подтягивать переменные окружения из их зависимостей. PR создан, но пока не смержен, поэтому $DBUS_SESSION_BUS_ADDRESS надо устанавливать вручную. Для этого предлагается использовать следующий кусок кода:

$ source /etc/user/conf.d/dbus

$ # в файле содержится вот такое:
$ cat /etc/user/conf.d/dbus
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

Прописываем его перед запуском Sway, убрав там dbus-run-session, а также в conf.d всех релевантных пользовательских сервисов.

pipewire

Наконец, после всех этих манипуляций, можно запускать pipewire:

$ rc-update --user add pipewire default
$ rc-update --user add wireplumber default
$ rc-update --user add pipewire-pulse default

…работает! Для себя я сделал вывод, что несмотря на то что реализованы еще не все желаемые фичи, такой сетап уже вполне пригоден к использованию. На данный момент пользовательские сервисы добавлены для следующих пакетов в репозиториях Alpine:

  • gnome-keyring
  • kanshi
  • pipewire
  • wireplumber
  • wlsunset
  • dbus
★★★★★

Проверено: hobbit ()
Ответ на: комментарий от gaylord

В защиту - если в проде шаг влево, то пердолева дохрена с systemd.
И я смотрю прямо сейчас на 3 варианта прода - Ubuntu, Debian (так как Proxmox) и Gentoo.

Тут только одна проблема - порог входа. Ubuntu с netplan/snap и своей обвязкой, Debian, где или «по старинке» или… И бородатые «молодые», которые через пол года почему-то на зп x3 пропадают.

Eulenspiegel
()

А за «наконец-то» пользование здоровым дистром - лайк. Смотрю, дорос! ))

Eulenspiegel
()
Ответ на: комментарий от gaylord

А в итоге поцтеринг в одни щщи затащил весь базовый Линукс. Ставишь systemd и тебе хорошо. А чтобы заменить его части, надо пердолиться. Вопрос – а зачем, если все уже написано, стандартизировано и протестировано?

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

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

l0stparadise ★★★★★
()
Ответ на: комментарий от l0stparadise

Получается, линукс-2025 - это когда жмешь несколько раз далее?

Минусы будут?

Мечта сбылась, выбора больше нет

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

kaldeon
()
Ответ на: комментарий от l0stparadise

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

Если тебе не нужно странного? Да. Если нужно странное, можно хоть с s6 развлекаться. Но это не нужно в 99.9% случаев.

gaylord
()
Ответ на: комментарий от gaylord

жрунала нет.

А он мне нужен этот ваш journald?

udev’а нет, надо ставить мертый eudev. logind нет, надо ставить мертвый elogind.

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

tmpfiles.d нет

А нахрена оно мне?

Логи сервисов на старте пишутся в отдельны файл, и то, если ты лично руками это напердолил.

У меня логи на важных хостах syslog-ng всё в базу кладёт. А на домашней тачке достаточно одного /var/log/messages.

Формат файла максимально нечитаемый.

Это ты сейчас не про бинарный файл journald?

Ротации логов тоже нет, надо пердолить logrotate.

По умолчанию настроен на /var/log/messages и ничего его на локалхосте пердолить не надо. А для важных хостов опять же всё кладётся в БД, а не в файл.

Нет resolved, надо пердолить руками через dnsmasq или openresolv или ещё какую срань

Ни то, ни другое, ни третье не использую.

Поддержка cgroups очень рудиментарная.

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

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

А он мне нужен этот ваш journald?

Мне нужен, моим коллегам нужен. А ты кто такой?

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

Потому что их upstream сдох. Дистрибутивы, не использующие systemd, планируют переход на апстримные systemd-logind и systemd-udevd.

МНЕ НИ НУЖНО

Ладно.

gaylord
()
Ответ на: комментарий от gaylord

Дистрибутивы, не использующие systemd, планируют переход на апстримные systemd-logind и systemd-udevd

у тебя есть какие-нибудь другие аргументы, бездарь? Или ты так и будешь тут разводить эту унылую фигню?

Lrrr ★★★★★
() автор топика
Ответ на: комментарий от Lrrr

у тебя есть какие-нибудь другие аргументы, бездарь? Или ты так и будешь тут разводить эту унылую фигню?

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

gaylord
()
Ответ на: комментарий от Lrrr

udev таки нужен. Ну или адекватная замена, только где её взять? eudev это тот же самый udev, гентушники его забросили потому что прикрутили к openrc оригинальный udev (хотя тут я слышал звон, могу ошибаться). Что такое logind я не знаю, какое-то ненужно для кедогномов что ли. Ненужно не нужно!

bread
()
Ответ на: комментарий от gaylord

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

WatchCat ★★★★★
()
Ответ на: комментарий от gaylord

Тебя никто и не заставляет.

Но ты упорно пытался мне доказать, что я страдаю.

Впрочем бывай, «непердолик» ты наш, плыви по своим «серьёзным» делам.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Но ты упорно пытался мне доказать, что я страдаю.

Нет? Я упорно доказываю, что в пердолинге нет смысла. То что есть люди, которые убеждены что в их случае пердолинг осмысленен, я не отрицаю. Это их право. Некоторые из них даже правы. Но люди с openrc дома, которые упорно доказывают, что он создает меньше проблем чем systemd… лол.

gaylord
()
Последнее исправление: gaylord (всего исправлений: 1)
Ответ на: комментарий от Lrrr

не нужно

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

не нужно ни в виде logind, ни в виде elogind

Нужно, чтобы менеджить сессии.

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

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

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

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

местные фанаты сустемд тут годами затирали, что resolved отдельный независимый сервис и вообще

Ну да, отдельный и независимый. Можешь отключить. Но нужно ли?

А сейчас оказывается что его отсутствие - это недостаток.

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

Кстати resolved надо конфигурировать руками точно так же как dnsmasq и openresolv, мне приходилось это делать.

В обычной ситуации он просто работает, и настраивать дополнительно что-то не нужно. Если нужно - то дистростроители плохо поработали. А если действительно нужно что-то специфическое - то это дело максимум пары строчек в /etc/systemd/resolved.conf

какой процент юнитов в репозитории арча в принципе использует cgroups, хоть пара наберется?

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

Да, без systemd они просто висят в системе, и из за дурости *nix приходится иметь менеджер которые будет следить за процессами, не только за детьми, но и тем жив он вообще или нет (актуально для сервисов). Сюда же входит завершение процессов при logout пользователя. Через cgroups еще удобно настраивать ограничения по ресурсам и доступу.

Все эти возможности, продвигают Linux ближе к нормальным системам. Например ближе к IBM OS/360 (1964 год), где тоже можно было определять ресурсы задач, и следить за их выполнением и получать информацию о статусе. А без systemd или чего то подобного, Linux не дотягивает до систем 1964 года, хотя даже сейчас не все возможности OS/360 реализованы, не зря она все еще жива.

Жду когда systemd добавят в Slackware, очень хочется пользоваться пользовательскими сервисами https://wiki.archlinux.org/title/Systemd/User. Сейчас я запускаю процессы при входе в систему, если они умирают по какой то причине, я могу это понять только если что то не работает ...

Искренне не понимаю, почему некоторые хотят оставаться в 1950х.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.