systemd 246

Я, конечно, не мамка, чтобы указывать, но хочется сделать сообщество чуточку лучше. :)

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

Там речь шла о шиме. Шим именно это и делает: заменяет пид1 с системд на на-системд. Если при этом происходит деградация в работе компонентов, то, как бы, очевидно, что до этого её пид1 предоставлял, даже если сами компоненты и не требовали именно пид1. Просто так оно есть, и вопрос именно в том, должна ли эта функциональность быть в пид1.

Для протокола: нет и нет.

При этом происходит деградация в работе тех компонентов, которые лезут в PID 1. Это, в первую очередь, logind, а во вторую очередь — те программы, которые напрямую запускают/останавливают другие юниты (навскидку: machined, timedated).

Как ты из этого сделал вывод обо всех остальных компонентах — решительно непонятно.

Про самые большие и важные из них (journald, logind, udev) выяснили

Я тут вот картинку в википедии нашёл: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg/1280px-Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg.png

Тут, вообще говоря, journald прям в пид1 нарисован. Равно как и networkd и «user session». Я, например, думал, что про журналд мы выяснили то, что он может работать без обращений к пид1. Но простите… а он что, по дефолту и правда в пид1 сидит, а не просто через месаджбас с ним контактирует? Тогда мы далеко не всё о нём ещё выяснили. :) Ну а нетворкд? Он почему в пид1?

Про юзер сешшн, который тоже в пид1, нашёл только вот это пока: https://wiki.archlinux.org/index.php/Systemd/User

The way systemd handles user sessions is pretty much in flux.
See [1] and [2] for some hints on where things are going.

Короче… чуть вышел с форума, и всё стало снова совсем не так «понятно». :)

Тут, вообще говоря, journald прям в пид1 нарисован. Равно как и networkd и «user session». Я, например, думал, что про журналд мы выяснили то, что он может работать без обращений к пид1. Но простите… а он что, по дефолту и правда в пид1 сидит, а не просто через месаджбас с ним контактирует? Тогда мы далеко не всё о нём ещё выяснили. :) Ну а нетворкд? Он почему в пид1?

Потому что картинка представляет собой 4.2. То есть это просто неправда.

Как ты из этого сделал вывод обо всех остальных компонентах — решительно непонятно.

Я и не говорил, что все. Я говорил, что такие точно есть, а значит, есть и повод разбираться. И я предполагал, что их не мало («почти все»), при этом, многократно просил либо дать их список, либо хотя бы сориентировать, насколько их много/мало. Впрочем, как выяснилось, это всё можно и в картинках на википедии почерпнуть.

Потому что картинка представляет собой 4.2. То есть это просто неправда.

ОКей. Тогда, может, вы сами дадите картинку, или ресурс, где всё будет «правда»? А то, от вас-то правду, как мы выяснили, тоже особо не получить. Так дайте хотя бы ссылку на неё. Где так же подробно, как и на этой картинке, будет всё расписано, или нарисовано - но по-другому.

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

Часть вызовов - заглушки, часть - переписана. См. https://github.com/elogind/elogind#differences-relative-to-systemd

Замечу, что вы легко могли найти эту информацию самостоятельно.

Я имел в виду, насколько оправдана потеря части функционала, когда мы заменили лишь пид1?

Ну вот есть timedated. Он помимо прочего позволяет включать/выключать синхронизацию времени с NTP-серверами, для чего обращается к systemd init для запуска/останова и включения/выключения соответствующих сервисов. Заменили PID 1 - как теперь запускать эти сервисы, учитывая 100500 различных вариантов init и их вариаций (в Debian, например, следует использовать invoke-rc.d)?

Никто не мешает написать аналог timedated, реализующий тот же dbus-интерфейс, - и ни GNOME, ни кто-либо другой не заметит подмены. Попытки такие были, но не осилили/надоело/оказалось никому не нужно/что-то ещё.

если мы на пид1 вешаем что-то, что сигруппами не управляет само, то это тогда может уже делать и сам логинд

Т.е. разработчики systemd зачем-то должны делать кучу работы, дублируя функциональность между частями проекта? Да ещё и учитывать весь тот зоопарк, что существует в мире GNU/Linux?

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

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

В большинстве случаев - для управления другими сервисами.

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

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

Почему вот тут говорят, что у гнома функционал деградирует, при чём, не из-за логинда? Так от чего там зависит гном, и зачем этим компонентам пид1 понадобился?

Для установки времени и часового пояса, управления синхронизацией времени через интернет, изменения hostname… А ещё у GNOME деградирует функциональность при отсутствии Network Manager, например.

Не понимаю, что вас так удивляет: если используется некий API для некоторой функциональности, то при отсутствии данного API теряется и данная функциональность. Тот же GNOME в FreeBSD несколько урезан именно в силу отсутствия там systemd, network-manager, udisks и проч.

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

Хоть и не ко мне, но: прежде чем спорить о модульности/монолитности systemd, необходимо для начала согласовать используемую терминологию. Что вы понимаете под модульностью?

Замечу, что вы легко могли найти эту информацию самостоятельно.

Она не столь важна в данном случае. Я лишь хотел убедиться, что нет разночтений в вашем же стане, так сказать. :)

Заменили PID 1 - как теперь запускать эти сервисы

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

Ну и плюс всякие картинки в википедии, типа этой: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg/1280px-Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg.png Которые говорят, что там очень много чего ещё сидит, в пид1…

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

Нет, я думал, елогинд может. Но уже объяснили, что нет.

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

а разработчики шим забили на него раньше, чем реализовали простейший функционал пускалки сервисов

Это ни разу не простейшая функциональность. Shim никогда не запускался как init, чтобы этим заниматься.

Не понимаю, что вас так удивляет: если используется некий API для некоторой функциональности, то при отсутствии данного API теряется и данная функциональность.

Меня в этом удивляет то, что вы приводите очень мало функционала в пример. Кроме логинда, вообще тривиальщина. Но, при этом, шимовцы её не делали, по вашим же словам. Вот и остаётся сомнение, подкрепляемое картинками с вики, что, может, это и не всё. :)

Тот же GNOME в FreeBSD несколько урезан именно в силу отсутствия там systemd, network-manager, udisks и проч.

Вот именно. Как нетворк менеджер, удискс и проч - связаны с пид1? Что он им такого даёт, чего не дал бы другой пид?

Что вы понимаете под модульностью?

Отправная точка: «заменить системд-пид1 - сложно», оставив при этом работать все его другие сервисы. Соответственно, под модульностью я понимаю такой факт: в пид1 там должно лежать только то, что в другой процесс перенести либо невозможно, либо технически не целесообразно. А всё остальное - там не лежит. Если это верно, то я могу быть уверен, что, несмотря на то, что «заменить системд-пид1 - сложно», тем не менее, эта сложность не привносится туда искусственно.

Shim никогда не запускался как init, чтобы этим заниматься.

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

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

Я лишь хотел убедиться, что нет разночтений в вашем же стане, так сказать. :)

Нет никаких станов. Я говорю от своего имени, а не какой-то группы.

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

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

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

Ну и плюс всякие картинки в википедии, типа этой: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg/1280px-Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg.png Которые говорят, что там очень много чего ещё сидит, в пид1…

Картинка очень странная. Убедиться, что она неверна, легко:

aleksej@lenovo:~$ pgrep -a systemd
1 /sbin/init
283 /lib/systemd/systemd-journald
297 /lib/systemd/systemd-udevd
498 /lib/systemd/systemd-timesyncd
553 /lib/systemd/systemd-logind
894 /lib/systemd/systemd --user
aleksej@lenovo:~$ 

Как видите, это всё - отдельные процессы, а не части PID 1.

На странице обсуждения этой картинки, кстати, также указывается на эту неточность:

The figure gives the wrong impression that logind was part of pid 1.

Картинка очень странная. Убедиться, что она неверна, легко:

Ну хорошо. А ваши же слова:

Тот же GNOME в FreeBSD несколько урезан именно в силу отсутствия там systemd, network-manager, udisks и проч.

Как минимум, и тут, и на картинке, присутствует нетворк менеджер. А в свписке ваших «отдельных» процессов его нет. С ним как дела обстоят?

«udisks и проч» я списываю на то, что их просто портировать не смогли, по независящим от пид1 причинам?

На счёт «user sessions» с картинки ещё подскажите, плиз. Её тоже нет там, где нарисована?

Upstart: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/package_manifest/chap-base-server-variant

Вот именно. Как нетворк менеджер, удискс и проч - связаны с пид1? Что он им такого даёт, чего не дал бы другой пид?

Никак. В FreeBSD они отсутствуют по другой причине.

Этот пример был приведён, дабы показать, что есть и ещё API, при потере которых страдает функциональность GNOME. И можно было бы спросить: «Что же это разработчики FreeBSD не реализовали такую простейшую функциональность?» - ну вот так сложилось, что поделать. И systemd здесь вообще не при чём.

Соответственно, под модульностью я понимаю такой факт: в пид1 там должно лежать только то, что в другой процесс перенести либо невозможно, либо технически не целесообразно

В общем-то, так и есть. Управление сетью - отдельный процесс, журналирование - отдельный процесс, управление сеансами - отдельный процесс, управление устройствами - отдельный процесс, управление временем - отдельный процесс…

aleksej@lenovo:~$ ls /lib/systemd/systemd*
/lib/systemd/systemd
/lib/systemd/systemd-ac-power
/lib/systemd/systemd-backlight
/lib/systemd/systemd-binfmt
/lib/systemd/systemd-bless-boot
/lib/systemd/systemd-boot-check-no-failures
/lib/systemd/systemd-cgroups-agent
/lib/systemd/systemd-cryptsetup
/lib/systemd/systemd-dissect
/lib/systemd/systemd-export
/lib/systemd/systemd-fsck
/lib/systemd/systemd-fsckd
/lib/systemd/systemd-growfs
/lib/systemd/systemd-hibernate-resume
/lib/systemd/systemd-hostnamed
/lib/systemd/systemd-import
/lib/systemd/systemd-importd
/lib/systemd/systemd-import-fs
/lib/systemd/systemd-initctl
/lib/systemd/systemd-journald
/lib/systemd/systemd-localed
/lib/systemd/systemd-logind
/lib/systemd/systemd-machined
/lib/systemd/systemd-makefs
/lib/systemd/systemd-modules-load
/lib/systemd/systemd-networkd
/lib/systemd/systemd-networkd-wait-online
/lib/systemd/systemd-pull
/lib/systemd/systemd-quotacheck
/lib/systemd/systemd-random-seed
/lib/systemd/systemd-remount-fs
/lib/systemd/systemd-reply-password
/lib/systemd/systemd-resolved
/lib/systemd/systemd-rfkill
/lib/systemd/systemd-shutdown
/lib/systemd/systemd-sleep
/lib/systemd/systemd-socket-proxyd
/lib/systemd/systemd-sulogin-shell
/lib/systemd/systemd-sysctl
/lib/systemd/systemd-sysv-install
/lib/systemd/systemd-timedated
/lib/systemd/systemd-timesyncd
/lib/systemd/systemd-time-wait-sync
/lib/systemd/systemd-udevd
/lib/systemd/systemd-update-utmp
/lib/systemd/systemd-user-runtime-dir
/lib/systemd/systemd-user-sessions
/lib/systemd/systemd-veritysetup
/lib/systemd/systemd-volatile-root
aleksej@lenovo:~$ 

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

«Нетворк менеджер», «udisks и проч» вообще никак не связаны с проектом systemd.

Как минимум, и тут, и на картинке, присутствует нетворк менеджер

На картинке NetworkManager нет. Есть networkd - это другое.

А в свписке ваших «отдельных» процессов его нет. С ним как дела обстоят?

В моём списке его нет, потому что он не часть systemd. А так с ним всё в порядке:

aleksej@lenovo:~$ pgrep -ai network
552 /usr/sbin/NetworkManager --no-daemon
...
aleksej@lenovo:~$ 

systemd-networkd в процессах нет, поскольку не запущен:

aleksej@lenovo:~$ systemctl status systemd-networkd.service 
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendo
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)
aleksej@lenovo:~$ 

На счёт «user sessions» с картинки ещё подскажите, плиз. Её тоже нет там, где нарисована?

Если под user session понимается пользовательский экземпляр systemd --user – то вы можете увидеть его в моём прошлом выводе, отдельным процессом.

В общем-то, так и есть.

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

Почему системд-шим пилили, если мы с вами вот так взяли, и сходу «постановили», что логинд лучше вообще не выносить, а cgmanager - не создавать? Они что, не понимали этого?

Зачем писали vdev, форкали еудев, если сам удев и так отлично живёт без системд? Они что, не знали про «ключик сборки»?

Я, как бы, понимаю, что «технические аргументы кончились» (у меня), но тем не менее. Эти все люди, что, просто хотели время впустую потратить, пиля велосипеды?

Если под user session понимается пользовательский экземпляр systemd –user

То, что на картинке они назвали «user sessions». :)

Эти все люди, что, просто хотели время впустую потратить, пиля велосипеды?

Так и есть.

Невежество вперемежку с нерациональностью.

Затем же, зачем в Devuan пересобирают пакеты, выкидывая libsystemd, хотя эта библиотека по определению ничего не делает в системах без systemd (PID 1).

Запусти любую ОС с systemd внутри и посмотри на список процессов. Там будут отдельные:

• Systemd (системный);
• systemd --user (по одному на каждого активного пользователя);
• logind;
• udev;
• journald;
• timesyncd (если используется);
• networkd (если используется);
• D-Bus.

И вообще, картинка больше про сигруппы, а не про архитектуру компонентов systemd. Если смотреть так — объединение всего в одну группу скорее всего значит не «живёт в одном процессе», а «живёт в одной сигруппе».

отдельный процесс, управление устройствами - отдельный процесс, управление временем - отдельный процесс…

А, стоп, я стормозил. Это ведь не доказывает, что они через либсистемд не лезут к пид1. С этим-то нам что делать? Они вообще линкуются с либсистемд? Надо каким-то образом определить, что они не только отдельные процессы, но ещё и могут работать с другими инитами, то есть, не лезут к системд никак.

Нет, они все живут в разных цгруппах.

Запусти любую ОС с systemd внутри и посмотри на список процессов. Там будут отдельные:

Да, но этого мало. Надо убедиться, что к пид1 не лезут. И это, видимо, не так уж тривиально сделать.

В очередной раз повторяю, что:

1. libsystemd != API systemd (вообще никак)

$ pacman -Qql systemd | grep -E '(/usr/bin|/usr/lib/systemd)/[^/]+$' | xargs -n1 ldd | grep libsystemd.so
        не является динамическим исполняемым файлом
ldd: предупреждение: у вас нет прав на выполнение `/usr/lib/systemd/import-pubring.gpg'
        не является динамическим исполняемым файлом
ldd: предупреждение: у вас нет прав на выполнение `/usr/lib/systemd/resolv.conf'
        не является динамическим исполняемым файлом
        
$

Затем же, зачем в Devuan пересобирают пакеты, выкидывая libsystemd, хотя эта библиотека по определению ничего не делает в системах без systemd (PID 1).

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

pacman -Qql systemd | grep -E ‘(/usr/bin|/usr/lib/systemd) /[^/]+$’ | xargs -n1 ldd | grep libsystemd.so

Так уже ведь сказали, что там всё с ней статически линкуют специально. Что тут лдд покажет?

Коллега, я ещё повторю мой пойнт, дело не только в запустить сервисы. В runit нужно подложить скрипт на bash, кто помешает одмину туда вписать rm - rf *, ну или ещё как-то ошибиться?

А в юнит системд фик что добавишь постороннее.

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

Ну а так есть генту, крукс, воид, кто мешает использовать? Но это не для промышленного использования. Слишком дорогие специалисты.

Так уже ведь сказали, что там всё с ней статически линкуют специально.

Кто сказал? Что значит «специально»?

Ну и разумеется, это пример так называемого вранья:

$ pwd
/home/intelfx/build/systemd/trunk

$ head -n10 PKGBUILD
# Maintainer: Christian Hesse <mail@eworm.de>
# Maintainer: Dave Reisner <dreisner@archlinux.org>
# Maintainer: Tom Gundersen <teg@jklm.no>

pkgbase=systemd
pkgname=('systemd' 'systemd-libs' 'systemd-resolvconf' 'systemd-sysvcompat')
_tag='a47534aa62edfddb2df86e2d0c208979f24dc8c2' # git rev-parse v${pkgver}
pkgver=245.6
pkgrel=8
arch=('x86_64')

$ makepkg -f
makepkg.conf: non-distcc: total 8 jobs
==> Сборка пакета systemd 245.6-8 (Пн 03 авг 2020 20:13:08)
<...>
         static libsystemd:                 false
         static libudev:                    false
<...>

(http://ix.io/2t5J)

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

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

Но потом один из членов начал продвигать вопрос, можно ли другим пакетам зависеть от конкретной системы инициализации, насколько, и в каких случаях. И именно вокруг этого была вся драма. Часть считала, что это вообще не вопрос, который был перед ними поставлен, и который они должны решать; часть считала, что нельзя принимать решение, не обозначив свою позицию и по данному вопросу. В конце концов пришли к окончательному решению, что этот вопрос не в их компетенции, а вопрос зависимостей впоследствии был вынесен на всеобщее голосование. Бурления потом было ещё много, но подавляющее большинство реальных разработчиков в нём не участвовало.

Почему системд-шим пилили, если мы с вами вот так взяли, и сходу «постановили», что логинд лучше вообще не выносить, а cgmanager - не создавать? Они что, не понимали этого?

Хотели попробовать обеспечить работу logind без systemd init - сделали. Это даже работало. Прекратило своё существование, скорее всего, поскольку оказалось не сильно-то и нужным, ибо все перешли на systemd (в том числе и Ubuntu, силами разработчиков которой это и пилили), а массового потока желающих поддерживать подобную прослойку не проявилось.

Зачем писали vdev, форкали еудев, если сам удев и так отлично живёт без системд? Они что, не знали про «ключик сборки»?

Без понятия. eudev я не трогал и не интересовался. Может, на будущее, если udev начнёт сильнее интегрироваться с systemd, - это нужно у них спросить.

Эти все люди, что, просто хотели время впустую потратить, пиля велосипеды?

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

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

Так вы хотите что сказать, что у вас вообще ни один бинарь в системе с либсистемд динамически не слинкован, и ни один компонент системд - так же и статически с ней не слинкован? И как такое понимать?

у вас вообще ни один бинарь в системе

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

Хотели попробовать обеспечить работу logind без systemd init - сделали. Это даже работало.

Если это работало, то, значит, по каким-то причинам, им не потребовалось из пид1 управлять сигруппами.

Так или иначе, надо бы ещё убедиться, что все указанные вами «отдельные процессы» не лазят к пид1 никак, кроме тех, кто лазит туда за пускалкой процессов и за сигруппами.

А, стоп, я стормозил. Это ведь не доказывает, что они через либсистемд не лезут к пид1. С этим-то нам что делать? Они вообще линкуются с либсистемд? Надо каким-то образом определить, что они не только отдельные процессы, но ещё и могут работать с другими инитами, то есть, не лезут к системд никак.

Так даже если лезут - какая разница? Это не делает systemd не модульным. Модульность - это про разделение сущностей на отдельные компоненты, а не про полную независимость этих компонентов.

Ничего не дорогие. Когда приходишь в контору, а там 50 серверов на линуксах с виртуалками. И никто не предлагает зарплаты уровнем повыше среднего, потому что уже есть какая-то древняя фиготень на федоре. И ошибиться настолько, чтобы стереть все это уже не ошибка, а намеренные действия. По мне так генту оптимально подходит для больших контор, которые закупают одинаковое железо мегатоннами и под это железо поднимается сервер, раздающий пакеты собранные для данного железа, прошедшие тестирование на тестовой машине. И да войд используют на серверах. Но баш может и в других местах пригодиться. А наниматься на работу для секса исключительно с системд это мне кажется не слишком весело. Эдакий потолок уже придуманный кем-то давить начнет через неделю даже у новичков. И опять же роутеры. Тут как-то выкладывали скрипт стабильного обновления OpenWRT. Сложнейший скрипт надо сказать. Но ведь лучше запихнуть его и забыть о проблемах. Пока что системд недостаточно себя зарекомендовал в плане свободы действий. Но если вокруг одни только злые одмины, которые ничего стараются не давать тем, кто вообще то тоже с мозгами и способен научиться, то да, может лучше и с ней париться. Ненавижу необоснованные ограничения. В любом случае пользователь полезет в инет со смартфона, и будет проклинать админов, заткнувших вконтактик.

Модульность - это про разделение сущностей на отдельные компоненты, а не про полную независимость этих компонентов.

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

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

1000+ виртуалок под одну систему это весьма редкие случаи.

Ну хорошо, так как нам установить, что лазят к пид1 только компоненты, которые хотят сервисы пускать, ну и логинд? Есть ли способ это по-быстрому проверить?

Вообще, думаю, было бы неплохо просто АПИ системд-пид1 глянуть. Из этого же сразу всё и выяснится.

Вообще, думаю, было бы неплохо просто АПИ системд-пид1 глянуть. Из этого же сразу всё и выяснится.

Да пожалуйста: https://www.freedesktop.org/wiki/Software/systemd/dbus/

Да пожалуйста: https://www.freedesktop.org/wiki/Software/systemd/dbus/

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

Её нет.

logind оперирует юнитами.

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

Но, с другой стороны, я не вижу тут АПИ для логинда. Вижу только юниты, джобы. Не подскажете, где здесь для логинда приблуда?

Вы имеете в виду управление cgroups? – Оно осуществляется через юниты типов scope и slice (см. метод StartTransientUnit()). Дополнительную информацию см. здесь: https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

logind оперирует юнитами.

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

В общем, видимо, я сдаюсь с этой затеей. Тут надо теперь по всем типам юнитов идти, вместо того, чтобы просто на АПИ посмотреть…