systemd 246

У него обязательно должен быть ПИД1?

Необязательно, но systemd уже управляет сигруппами для всех запускаемых им сервисов. Пользовательские сессии для него — такие же сервисы (вернее, slice’ы). Поэтому и сделали так, что logind делегирует управление сигруппами тому, кто его вызывает. Скорее всего, в elogind вместо интерфейса с systemd просто впилили управление сигруппами напрямую. Кстати, интересно, как оно будет работать в связке с OpenRC, который вроде как тоже умеет работать с cgroup v2?

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

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

Дальше будет как на винде - сверху кнопки для эникеев, а всё остальное - под капотом, и нефиг туда лазить, если не знаешь. Линукс вырос из системы для программистов в систему для промышленного использования всеми (а идиотов, как известно, 95%).

Точнее и не скажешь. Этот ваш systemd лишь часть преобразований способствующих в том числе и линукс на десктопе, о котором так долго мечтали те самые поклонники «линукс в массы». За что так сказать боролись..

Верно ли я понимаю, что sуstemd-shim, в частности, был призван именно логинд отвязать?

Да.

Чем там был плох cgmanager, почему не взлетело?

Не взлетело потому, что не нашлось никого, кто бы стал его далее развивать: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508.

С разработкой elogind нужда в подобной прослойке вообще отпала.

Как я понимаю, список логиндом не ограничивался. Какие ещё компоненты пытались с помощью шима отодрать? Если такие компоненты есть (кроме логинда) - опишите плиз, почему они сейчас прибиты, и почему не удалась попытка их отодрать шимом.

ЕМНИП, systemd-shim создавался конкретно из-за logind. Остальные компоненты не являются критически необходимыми для запуска того же GNOME - оно лишь потеряет часть функциональности.

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

Судя по правилам сборки в Debian, проблем нет. Единственное, udev собирается с опцией link-udev-shared=false, что приводит к статической линковке с библиотекой systemd, а не динамической (что привело бы к зависимости от пакета с этой библиотекой).

По идее, отвалится лишь запуск сервисов systemd по событиям udev с помощью ENV{SYSTEMD_WANTS} - но этого стоило ожидать. В остальном они вполне независимы.

Скорее всего, в elogind вместо интерфейса с systemd просто впилили управление сигруппами напрямую.

Означает ли это, что он с системд в принципе работать не способен?

С разработкой elogind нужда в подобной прослойке вообще отпала.

А что значит, отпала? Чем елогинд принципиально отличается от более старых попыток отцепить логинд от системд? Он ведь тоже с ним, как бы, конкурирует, как раньше пытался cgmanager?

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

Ну хорошо, а зачем терять часть функционала? По сути-то какая разница, ведь всё равно эти компоненты (какие именно, кстати?) в системд «интегрированы», отдельно не живут, и альтернативу им пока никто не запилил. Или?

Единственное, udev собирается с опцией link-udev-shared=false, что приводит к статической линковке с библиотекой systemd, а не динамической (что привело бы к зависимости от пакета с этой библиотекой).

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

Фреско пересмотрел?

Нет. Что это и где посмотреть?

Я не считаю Linux частью Unix-мира.

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

Хотите юникс — пользуйтесь юниксом, пишите ПО и скрипты только по стандарту POSIX и обязательно тестируйте его на корректную работу на всех реализациях Unix System V Release 4 (например, Solaris или HP/UX), а иначе это всё — позерство.

Первым делом нужно выкидывать wayland и systemd.

ЕМНИП, systemd-shim создавался конкретно из-за logind.

Тогда вообще ничего непонятно. https://packages.debian.org/jessie/systemd-shim

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

А если предположить верной вашу теорию, то выходит, что он создавался вообще не для «помощников systemd», а для гнома, чтобы тот работал без логинда? Или же выходит, что другие компоненты системд все стучатся к логинду? Но зачем бы?

systemd-shim — эмулирует API systemd (PID 1), чтобы logind (и прочие тулзы) как-то работали без модификаций.

elogind — выкорчёвывает из самого logind вызовы к API systemd (PID 1) и заменяет их заглушками, чтобы не приходилось ставить больше вообще ничего.

Гном работает с API logind, потому что ConsoleKit сдох. Чем это API реализовано — systemd+logind, или systemd-shim+logind, или elogind, или LoginKit, или тысячей мартышек с печатными машинками и сниффером dbus — вообще без разницы.

Так понятно?

systemd-shim — эмулирует API systemd (PID 1), чтобы logind (и прочие тулзы) как-то работали без модификаций.

Можно ли список «прочих тулзов», которые шим охватывал, и причины, по которым они лезут к пид1 (про логинд Rootlexx пояснил уже). И, правильно ли я понимаю, что шим перенаправлял эти вызовы различным сервисам, например, cgmanager, который не пид1? То есть, он именно пытался сделать сервис модульным. Не получилось. Но попытки были, тот же cgmanager - был. Почему же в системд это всё в пид1, если было доказано (хоть и не доведено до конца), что можно и по-другому?

elogind — выкорчёвывает из самого logind вызовы к API systemd (PID 1) и заменяет их заглушками, чтобы не приходилось ставить больше вообще ничего.

Просто заглушками? Какое поведение при этом поменяется? :)

Так понятно?

Да, про шим vs logind я, вроде, распутался теперь. Спасибо. Добавьте, плиз, подробностей по вопросам выше.

Дык выкидывай, кто тебе не даёт?

И, правильно ли я понимаю, что шим перенаправлял эти вызовы различным сервисам, например, cgmanager, который не пид1?

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

Можно ли список «прочих тулзов», которые шим охватывал

Спроси у авторов «шима».

Просто заглушками? Какое поведение при этом поменяется? :)

Спроси у авторов elogind.

Тогда в студию аргументы чем переусложнен runit или OpenRC.

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

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

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

А что значит, отпала? Чем елогинд принципиально отличается от более старых попыток отцепить логинд от системд?

systemd-shim ориентирован на бесшовный запуск logind из состава systemd на системах без systemd init. elogind же - это попытка вытащить logind из systemd на уровне исходного кода, сделав его полностью автономным.

Иными словами, если systemd-shim пытается обеспечить запуск существующей оригинальной реализации logind, то elogind - это альтернативная реализация (хоть и почти полностью основанная на оригинальной).

Он ведь тоже с ним, как бы, конкурирует, как раньше пытался cgmanager?

cgmanager не конкурировал с logind. Это программы с разным назначением.

Ну хорошо, а зачем терять часть функционала?

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

альтернативу им пока никто не запилил. Или?

Попытки были:

• https://www.reddit.com/r/linux/comments/2fsh5m/systembsd_a_systemd_compatibility_layer_for_bsd/

• https://gitweb.gentoo.org/proj/openrc-settingsd.git/

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

Статическая линковка позволяет уменьшить число зависимостей.

Связывание с библиотекой из состава systemd необязательно означает зависимость от systemd init. Та же libsystemd как раз и создана с прицелом на обеспечение возможности работы приложений с systemd без их привязки к systemd init: если текущий init не systemd, то многие функции просто ничего не делают.

там опять же были заглушки.

Нет, секунду! cgmanager там был? Это разве заглушка? Допускаю, что какое-то количество заглушек там было, но вряд ли это и было целью разработки. Могли просто не доделать, например.

Спроси у авторов «шима».

На данный момент требуется понять, всего лишь, какие компоненты завязаны на АПИ системд-пид1, и насколько обосновано этому АПИ в пид1 находиться. Если вы можете ответить на этот вопрос не лазя за примерами в шим - то отлично, про шим спрашивать не буду, ответьте без него. Я думал, с шима будет проще начать.

Спроси у авторов elogind.

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

А если предположить верной вашу теорию, то выходит, что он создавался вообще не для «помощников systemd», а для гнома, чтобы тот работал без логинда?

Как именно вы пришли к такому выводу из моих слов - загадка. Я же наоборот говорю: systemd-shim создавался, чтобы обеспечить работу GNOME (и других) с logind, но без systemd init.

elogind же - это попытка вытащить logind из systemd на уровне исходного кода, сделав его полностью автономным.

ОК, спасибо. Уже выше intelfx это разъяснил. Вы подтверждаете его слова о том, что там обращения к системд заглушками заменены? Просто хочу удостовериться, что нет разногласий.

Странный вопрос.

Я имел в виду, насколько оправдана потеря части функционала, когда мы заменили лишь пид1? Вы ведь пока только про логинд пояснили, да и то, если мы на пид1 вешаем что-то, что сигруппами не управляет само, то это тогда может уже делать и сам логинд. То есть, даже тут потеря функционала не обязательна. А что там в других случаях происходит? Должен ли этот функционал и правда в пид1 находиться, и теряться при замене его на не-системд? Должны ли другие сервисы, помимо логинда, отваливаться и/или деградировать при этом? Зачем им пид1, проще говоря?

то многие функции просто ничего не делают.

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

Как именно вы пришли к такому выводу из моих слов - загадка.

Это да, загадка, ну мне intelfx уже этот момент «распутал». Я полагал, что елогинд и шим - одного поля ягоды, так как про елогинд вообще ничего не знал.

Нет, секунду! cgmanager там был?

Без понятия.

На данный момент требуется понять, всего лишь, какие компоненты завязаны на АПИ системд-пид1

Кому требуется?

и насколько обосновано этому АПИ в пид1 находиться

man cgroup single writer

Ну хорошо, упрощу вопрос: почему патчи елогинда не берут в апстрим системд?

А почему их должны куда-то брать? Elogind — это костыльная поделка, задачей разработчиков которой было выкорчевать куски кода с мясом и надеяться, что оставшаяся оболочка будет подавать признаки жизни.

Видимо, не просто так - заглушки им чем-то не нравятся?

Отвечу вопросом на вопрос. Вот есть в ядре Linux генератор случайных чисел. Ты пишешь патч, который заменяет этот генератор на функцию, которая всегда возвращает 42. В принципе, всё продолжает работать.

Примут ли, по-твоему, этот патч в апстрим ядра, и если нет, то почему?

Или, ещё более простой вопрос: если системд такой крутой и модульный, зачем вообще такие проекты, как шим и елогинд, рождаются и умирают?

Потому что они построены вокруг почти единственной жёсткой зависимости в кодовой базе systemd (вокруг желания её устранить). По успеху (а точнее, неуспеху) этих проектов можно сделать косвенный вывод о том, что эта зависимость там не просто так.

То есть создать файлик в каталоге как это делает в случае с runit, и написать там какой сервис стартует это невероятно сложнее системд? Надо ведь сначала обозреть какие системы инициализации уже существуют прежде чем сравнивать. А тут как будто речь про OpenRC. Ведь никто не мешает точно так же взять готовый рецепт для данной системы инициализации. И там точно также ничего не стартует если писать с зависимостями. Например вход на терминал такой-то стартует sway. Даже в шиндовсе сначала проверяют работоспособность скрипта на виртуалке. И никто не жалуется как ни странно.

Судя по описанию, крутая штука. Надо будет потыкать

Кому требуется?

Не то, чтобы «кому», а «для чего». Чтобы понять, монолитен ли системд, или нет. А не об этом ли тут срач на 10 страниц уже?

man cgroup single writer

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

Потому что они построены вокруг почти единственной жёсткой зависимости в кодовой базе systemd

Вот это и непонятно. Вы говорите, что она единственная. А, при этом, похоже, что АПИ либсистемд чуть ли ни вообще все его компоненты и используют. И вот мы выяснили, что некоторые могут быть отцеплены, с деградациями функционала. В случае с удев - с несущественными. С логинд - видимо, с существенными, но там причина ясна. Ну журналд, допустим, независимый. А ещё 1024+ компонента, линкующиеся с libsystemd? Почему вот тут говорят, что у гнома функционал деградирует, при чём, не из-за логинда? Так от чего там зависит гном, и зачем этим компонентам пид1 понадобился? И тд.

Вы делаете утверждение о модульности системд, но достаточных доказательств я не вижу. Хотя то, что хотя бы по 2-3 модулям прошлись - уже плюс, но не достаточно.

А, при этом, похоже, что АПИ либсистемд чуть ли ни вообще все его компоненты и используют.

libsystemd != systemd (PID 1)

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

Мог бы. А среда GNOME могла бы использовать Qt вместо GTK. А Microsoft мог бы написать ОС Windows поверх ядра Linux. И что?

Для всего этого соответствующие программные продукты пришлось бы почти полностью переписать. Почему и с какой целью разработчики systemd должны делать двойную работу?

Вы делаете утверждение о модульности системд, но достаточных доказательств я не вижу. Хотя то, что хотя бы по 2-3 модулям прошлись - уже плюс, но не достаточно.

За чтением исходников systemd вслух просьба обратиться в Job.

Жак Фреско, проект венера.

Посмотри, найдешь единомышленников.

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

Всё сломается на моменте, когда пользователь захочет поставить себе в систему, например, Docker (если предположить, что Docker уже использует cgroups v2 — точно не помню).

Так от чего там зависит гном, и зачем этим компонентам пид1 понадобился? И тд.

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

libsystemd != systemd (PID 1)

Это да, если линковка статическая. Но там будет деградация, да и вообще, все ли его компоненты «оживут» при таком подходе?

разработчики systemd должны делать двойную работу?

Я не говорил, что так надо сделать. Если системд для чего-то очень надо настраивать сигруппы именно из пид1, то ок, пускай тогда елогинд отдельным проектом живёт, просто он может тогда не заглушки использовать, а сам сигруппами управлять (но почему-то этого не делает). С другими компонентами бы понять, что делать.

За чтением исходников systemd вслух просьба обратиться в Job.

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

Docker (если предположить, что Docker уже использует cgroups v2 — точно не помню).

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

Это уже скорее не к пользователям systemd, а к разработчикам GNOME вопрос.

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

Это да, если линковка статическая.

Каким местом здесь вообще линковка?

libsystemd в принципе никак не связан с API systemd.

Так ведь это вы утверждаете, что он модульный, а не я.

Не-а, всё совсем не так. Сюда пришли люди, которые утверждали, что он монолит. Было продемонстрировано несколько контрпримеров. Дальше не моя забота.

Я к тому, что если в системе окажутся два процесса, которые хотят рулить cgroup v2 — случится конфликт (кто первый запустился — того и тапки группы). Об этом как раз Rootlexx писал, когда объяснял, почему logind завязан на systemd.

где зависимости есть, а где их нет, и почему гном деградирует - теперь тоже непонятно

В принципе, можно заглянуть в пакеты GNOME для Gentoo и посмотреть, что и где они там патчат. Из патчей должно стать понятно, где есть (не)явные зависимости от systemd. Но мне лень. :)

Каким местом здесь вообще линковка?

Как я понял, чтобы «скрыть» зависимость от системд, его компоненты стали линковать с либсистемд статически. Тогда они, вроде как, «работают» и без него, и «libsystemd != systemd». Если же вы динамически линкуете, то, без systemd у вас по-просту нет соответствующей либы, так как она же в его пакете сидит, а он не установлен. Но насколько хорошо они без него работают - непонятно. А главное, непонятно, зачем им вообще нужен пид1 - может и без него бы отлично жили?

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

Так проблема в том, что контр-примеры нужно дать по ВСЕМ компонентам, ну или хотя бы по подавляющему большинству. Тогда - не монолит. А тут наоборот: если вам хоть один контр-пример дадут, где он монолит (и это не будет иметь технических обоснований, как с логиндом), то этого уже хватит.

Как я понял, чтобы «скрыть» зависимость от системд, его компоненты стали линковать с либсистемд статически. Тогда они, вроде как, «работают» и без него, и «libsystemd != systemd». Если же вы динамически линкуете, то, без systemd у вас по-просту нет соответствующей либы, так как она же в его пакете сидит, а он не установлен. Но насколько хорошо они без него работают - непонятно. А главное, непонятно, зачем им вообще нужен пид1 - может и без него бы отлично жили?

Отборный бред, даже комментировать не стану, всё не так.

Так проблема в том, что контр-примеры нужно дать по ВСЕМ компонентам

«Имеющий глаза да увидит»

Я к тому, что если в системе окажутся два процесса, которые хотят рулить cgroup v2

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

Отборный бред, даже комментировать не стану, всё не так.

Уж даже и не знаю, какое слово вам тут пояснить. Вероятнее всего, вот это: «А главное, непонятно, зачем им вообще нужен пид1 - может и без него бы отлично жили?» Тут имеется в виду, что тот функционал, который они хотят через либсистемд получить от пид1, вполне мог бы быть реализован в другом сервисе, не в пид1. Но они все зачем-то лезут к пид1. Зачем?

Ничего пояснять не надо, в процитированном нет ни единого верного утверждения.

То есть создать файлик в каталоге как это делает в случае с runit, и написать там какой сервис стартует это невероятно сложнее системд?

Коллега, помимо «создать файлик» есть ещё проблемы повторения на 100500 серверов, выдачи прав админам, траблшутинга и так далее и т.п.

Я думаю, RH вполне мог взять любую другую систему инициализации, и runit, и OpenRC, и Upstart, но в итоге после добавления всех хотелок всё вышло бы что-то systemd-подобное, как оно есть в Windows и как оно есть в OSX.

Ничего пояснять не надо, в процитированном нет ни единого верного утверждения.

Да не важно.

• libsystemd к pid1 лезет? Да/нет?
• она линкуется со всеми компонентами системд? Да/нет? (если нет - с какими не линкуется, или, наоборот, с какими линкуется?)

libsystemd к pid1 лезет? Да/нет?
она линкуется со всеми компонентами системд? Да/нет? (если нет - с какими не линкуется, или, наоборот, с какими линкуется?)

Да не важно (c)

Docker ничего не знает о logind. Он может работать с сигруппами либо напрямую сам, либо обращаясь к systemd — не к logind. Если в системе cgroup-driver’ом будет elogind — Docker об этом не узнает и либо выпадет в ошибку при запуске (если elogind запустится раньше), либо займёт сигруппы сам и не даст нормально работать уже elogind.

Да, я ступил.

ОК, ясно. Тогда и с логиндом тоже всё понятно. :) Но блин… это ж только 2 компонента из десятков… И к системд лезут, как я понимаю, практически все из них. Или нет?

И к системд лезут, как я понимаю, практически все из них. Или нет?

Они начинают что-то подозревать (c)

Что подозревать? Деградации в гноме есть при отсутствии системд, при чём, не вызванные логиндом? Значит, лезут.

Значит, лезут.

Запретити им!!! :-D :-D :-D

Возможно. Возможно нет. Все не проверял, ибо не было необходимости. Про самые большие и важные из них (journald, logind, udev) выяснили, а другими компонентами (кроме, собсно, systemd) я не пользуюсь, по крайней мере явно. Некоторые из компонентов вообще по сути своей являются хелперами, которые выполняют разные задачи при старте системы и запускаются как отдельные сервисы (это к слову о монолите).

Деградации в гноме есть при отсутствии системд, при чём, не вызванные логиндом?

Кто вам это сказал?

Значит, лезут.

Качество вашей логики, конечно, на высоте.

Не троллируй почём зря. :)

Вдруг человек правда хочет хоть что-то понять? А так ты его только оттолкнёшь от попыток разобраться.

Кто вам это сказал?

systemd 246 (комментарий)

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

Качество вашей логики, конечно, на высоте.

Как и ваших ответов.

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

И где здесь о том, что «остальные компоненты» требуют PID 1?

Справедливо.