Добрый день.
В связи с «массовым» интересом к проблемам systemd, которых до systemd не было, появилась пара замечаний к пакетам calculate.
Дело в том, что относительно давно я установил к себе в систему systemd и по различным мануалам, а порой и через «libastral», в общем-то заставил его опять же относительно не плохо работать. При этом сохранилась возможность работы с openrc (в командной строке ядра всего-лишь добавляется/удаляется real_init=/bin/systemd).
Но, с некоторого времени (без объявления войны) systemd стал конфликтовать с sys-fs/udev.
Таким образом в системе теперь наблюдаются несколько реализаций udev — sys-fs/udev, sys-fs/eudev, sys-apps/systemd, а также виртуальный — virtual/udev.
Отставляя в сторону возможность совместной эксплуатации openrc|systemd, возникла проблема зависимостей некоторых пакетов от sys-fs/udev, когда эту ситуацию решает замена на virtual/udev.
sys-fs/udev required by (*net-print/foo2zjs-20110512::calculate*, installed)
>=sys-fs/udev-197 required by (*sys-apps/calculate-install-3.1.4_beta1-r3::calculate*, installed)
>=sys-fs/udev-197 required by (*sys-kernel/calckernel-3.4.18-r14::calculate*, ebuild scheduled for merge)
sys-fs/udev required by (*net-print/hplip-plugin-3.12.10a::calculate*, installed)
Вопрос, стоит ли выделять такие особенности в баг-трэккер или достаточно уточнить на форуме?
P.S.:
Также обсуждения по данному вопросу, с которым я столкнулся, можно посмотреть тут
Честно говоря писать не о чем. Systemd разочаровал. Проблемы наблюдаются постоянно.
Вначале поразила скорость загрузки, ~15c до экрана xdm.
Но, со временем, с увеличением функциональности и добавлением демонов (сервисов по терминологии systemd) скорость стала такой же как и в openrc.
Вчера измерял — загрузка до появления slim в systemd >34с, в openrc, с включенным параллельным режимом загрузки, 35c. Разница в ~0.5с.
Поскольку взаимодействие systemd с демонами основано на других принципах, то наблюдаются очень странные косяки.
К примеру вчера. После правки slim.service, которая потребовалась с переходом jast4fun на xorg-1.14, slim перестал правильно отображаться с 2-мя мониторами, стал пропадать/удаляться xorg.conf,… но это отдельная песня.
Так вот, поправил штатно сервис, и процесс с PID=1 упал. Совсем. Любые попытки запустить любой сервис выдавали что-то типа не могу связаться, служба dbus не зарегистрирована и так далее. Более того, reboot, shutdown, halt тоже отказались перегружать систему, так как процесса с PID=1 нет.
Жал ресет. Для меня это нонсенс.
Очень большие траблы с chroot. Нет, смонтировать и работать можно, но вот отмонтировать /mnt/gentoo/sys/fs/cgroup/systemd уже нельзя, занят.
И это только из того, что вспоминается.
В общем пришёл к выводу, что обычный init и openrc защищены от криво/плохо-написанных скриптов инициализации что называется by design. В крайнем случае не запустятся сами демоны.
Systemd от этого практически не защищён. При этом с увеличением функциональности выигришь из-за чего и начался весь сыр-бор (а это отказ от форка) оказался никакой.
А так, приходится держать и systemd-logind.service, и ck-launch-session. Сам systemd устанавливается штатно из одноимённого оверлея, плюс такой же одноимённый глобально выставленный флаг. С fbcondecor не работает, plymouth так и не победил. Да и не особо старался.