Control: tags -1 - moreinfo
Many thanks for this.
Control: tags -1 + moreinfo
Post by Mark Hindley
For desktops to be installable on such systems, policykit-1 needs to depend on
the newly approved virtual packages default-logind and logind. In the latest
upload of src:systemd, libpam-systemd provides default-logind.
Sorry for the delay in getting back to you on this. Non-critical changes
to important components like policykit-1 did not seem like a good idea
during the buster release freeze.
Yes, I understand that. It also seems to me that now, early in the bullseye
cycle, is a good time for such changes.
Does polkit work correctly on systems that use elogind, without any
further source or binary changes? It is not enough that a logind-like
service is merely installed and monitoring sessions: to keep polkit's
core functionality working, it has to be able to query logind's state
via libsystemd.so.0 APIs.
Yes, it works in my testing. I have had a number of other reports of success too
with a variety of desktops (xfce, mate, budgie, cinnamon and even gnome).
Since #923244 was resolved in version 241.1-1+debian1, libelogind0 is ABI
compatible with libsystemd0 and exposes the same symbols for runtime linking,
although providing a subset of functionality. This is explained fully in the
libelogind0 package description: sd-login(3), sd-bus(3) and sd-id128(3) APIs are
implemented in full with most other functions returning -ENOSYS. libelogind0
also provides a libsystemd.so symlink so that applications compiled against
systemd work with libelogind0 at runtime.
For example, when polkitd calls sd_pid_get_session(), if the system is
using elogind, the API call needs to return whether pid is part of an
Please could you describe how this is meant to work on systems that use
elogind? Which packages are meant to be installed to make this work?
- libpam_systemd is invoked on login and logout
- libpam_systemd communicates with systemd-logind to update its knowledge
of login sessions
- polkitd is linked to libsystemd.so.0, which is provided by libsystemd0
- libsystemd0 communicates with systemd-logind via D-Bus, or by reading
files in /run/systemd that are considered private to the combination
of systemd-logind and libsystemd0 (mainly /run/systemd/seats and
/run/systemd/sessions, I think)
Which parts of that architecture get replaced when using elogind?
In exactly the same way. libpam-elogind is invoked at login/logout and updates
elogind's record of sessions. polkitd calls functions in libelogind.so via its
libsystemd.so symlink to retrieve information on users, sessions and their
When a bug is reported in policykit-1 on a system that is using elogind,
does the reportbug-generated message template indicate that? Is there
someone among the elogind maintainers who can help with such bugs if
they appear to be integration issues between policykit-1 and elogind?
(If the reportbug-generated message template with your proposed patch
doesn't currently indicate systemd-logind vs. elogind, it should be
possible to fix that by putting appropriate runes in
I will be very happy to work to resolve issues related to elogind and its
integration with other packages. You are correct that a reportbug template
including that information would be useful.
Post by Mark Hindley
There is a separate issue about backend support for elogind. I will
open a separate bug for that.
Does that separate bug exist, or has the question of backend support
become irrelevant due to changes in the design of how elogind fits into
Debian since you opened this bug?
Yes that was #923244 which has now been solved by runtime ABI compatibility
rather than the original suggestion of alternative backend packages.
Post by Mark Hindley
Please explain your decision on why desktops for other
init systems are excluded (even in sid).
Please don't assume that the absence of action is a deliberate decision.
All of policykit-1's maintainers (both upstream and in Debian) mostly
work on other things and don't have a huge amount of time available for
policykit-1. This makes us reluctant to risk creating the possibility
of non-functional combinations of packages that will take more of our
time to debug.
I understand. To help prevent that libelogind0 conflicts with systemd itself so
that the non-functional situation of systemd with libelogind0 is not possible.
Thanks and best wishes.