Re: Should libpam-elogind Provide libpam-systemd ?
On Sat, 03 Nov 2018 at 00:08:50 +0100, Adam Borowski wrote:
> On Fri, Nov 02, 2018 at 10:22:58PM +0000, Simon McVittie wrote:
> > libpam-elogind is very unlikely to be enough to satisfy
> > dbus-user-session's dependency, for instance, unless elogind has taken
> > an excursion into systemd-like service management while I wasn't looking.
>
> And for that reason dbus-user-session has Depends: systemd, which describes
> this requirement just fine. It runs systemd's user parts.
No, a dependency on systemd merely guarantees that /lib/systemd/systemd
and .../systemd-logind binaries exist. It does not provide the system
integration that dbus-user-session relies on, which is: whenever uid N has
at least one login session open, there is an XDG_RUNTIME_DIR for uid N
(created by systemd-logind), and a `systemd --user` process running as
uid N (systemd system unit user@N.service, started by pid 1 on request
from systemd-logind).
You might be misinterpreting dbus-user-session as being the component
that runs `systemd --user`? If so, it isn't - it's the other way around,
`systemd --user` runs a dbus-daemon because dbus-user-session asks it to.
To get `systemd --user`, you need a working systemd-logind (represented by
a dependency on libpam-systemd, meaning you have the necessary pam_systemd
PAM module to tell it about your login sessions), and you also need
systemd as pid 1 (which is not something we can express in dependency
relationships, but is approximated by Recommends: systemd-sysv).
If you don't have `systemd --user` working, then dbus-user-session will
not have the opportunity to start a dbus-daemon via socket activation,
which means it doesn't provide its intended "API" either.
If people who prefer elogind want to add appropriate glue to
dbus-user-session to arrange for D-Bus clients to be able to connect to
$XDG_RUNTIME_DIR/bus and find a working bus there even in the absence
of `systemd --user`, I'm open to suggestions. Implementing this would
probably require an additional PAM module that starts one dbus-daemon
per XDG_RUNTIME_DIR, or that starts a helper process that uses the
socket activation protocol to start the actual dbus-daemon on-demand,
or something; I'm not going to maintain such a thing myself, but I
wouldn't mind adding it as an alternative dependency.
However, note that if you want multiple parallel dbus-daemons per uid,
in particular one per X11 display, then dbus-user-session is not for you,
and you should continue to use dbus-x11 or some third party implementation
of the dbus-session-bus virtual package instead. Packages that use the
session bus should depend on "default-dbus-session-bus | dbus-session-bus"
so that you can continue to use dbus-x11 to satisfy their dependency,
unless they specifically rely on the "one bus per XDG_RUNTIME_DIR" model.
smcv
Reply to: