community/elogind: conflicts with other services depending on cgroups
On startup, elogind mounts "hybrid" cgroups by default (because elogind service does not "depend" on cgroups, and because elogind was built with hybrid support by default; see comments for more details).
If any of the services launched after that depend on cgroups, they will overwrite the content of /sys/fs/cgroups with freshly mounted cgroups2, breaking elogind.
For example, this means that for the following startup sequence: elogind, greetd, incusd: the user will be unable to log into system and get to their DE, because there will be no elogind session after they log in, and the DE won't be able to get a seat from elogind (additionally, XDG_RUNTIME_DIR will also not be set).
And this in turn means that a user that has their system configured and that successfully uses their DE, will have everything broken the moment they install incusd, do rc-update add incusd
and restart.
Previous title: community/greetd: conflicts with other services
Previous description:
There is not a lot of information in Alpine wiki about greetd, but it seems to be the recommended way of using the system with elogind / desktop environments.
Installing greetd-openrc
, greetd-agreety
and enabling greetd
service (with doas rc-update add greetd
) on a clean Alpine system (plus elogind
plus polkit
), and patching the system (as described in #15780 (closed)) to make agreety
usable, works fine on a clean system.
However, installing more unrelated services sometimes breaks greetd
, so that after logging in with agreety
, XDG_RUNTIME_DIR
is no longer set, loginctl
reports no active sessions, and wlroots-based window managers (and probably other desktop environments as well) not starting because elogind cannot open seat ("logind.c: Could not get primary session for user: No data available").
It seems to be caused by the fact that greetd
starts alongside all the other services, before some of them (which also means that often, I'll see boot log entries about some services starting after agreety displayed its login prompt); and adding more services to the system sometimes results in greetd
starting before polkit, which is probably what is causing the issues.
I'm not sure how things works with OpenRC, but perhaps greetd package should depend on elogind and polkit (or there should be some meta package for them all), and greetd service should only start after elogind and polkit. Or maybe greetd can start earlier, but greeter should be postponed until init is complete. Otherwise things are very brittle and can break at any moment; and it could be very difficult to understand what exactly causes the problem (took me a while to debug my window manager not starting after a reboot, and trace it down to this issue and to me having installed incus a couple of days ago).