Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
On Sun, 01 Dec 2019 at 22:02:31 +0100, Simon Richter wrote:
> In that particular case, the user session must be available to allow
> activation of gsettingsd via dbus
There is no such thing as gsettingsd. Presumably you mean dconf-service
(which is conceptually one of many backends, although in practice it's
the one that is nearly always used).
> dbus-x11 is not a complete solution -- it makes a "session" dbus
> instance available, but without dbus activation of services
This is not true. Any dbus-daemon[1], including the one started by
dbus-x11, provides D-Bus activation (services started on-request as
children of dbus-daemon, which acts as a crude service manager). This
functionality has been present since 2003-2004 for session buses,
depending where you draw the line for it being feature-complete, and
since 2007 for the system bus.
The dbus-x11 problem that is most relevant here[2] is that because the
session bus is run as a child process of (a somewhat arbitrary process
inside) an X11 desktop session, those D-Bus-activated services cannot
be managed by `systemd --user`, even on systems that have it; and
the session bus and its session services are not visible/available to
programs that run as `systemd --user` services, such as gpg-agent. This
is because `systemd --user` is "bigger than" the per-X11-display session
bus provided by dbus-x11, so anything in its scope that tries to connect
to "the" session bus is faced with the question: which session?
Conceptual model of dbus-user-session on systems with `systemd --user`:
"the system" (system services, etc.)
\- uid 1000
\- systemd --user
\- dbus-daemon
\- D-Bus-activated services without SystemdService=
\- D-Bus-activated services with SystemdService=
\- non-D-Bus-based user services
\- login session 1 (X11)
\- gnome-session, startkde, ~/.xinitrc or equivalent
\- window manager
\- applications
\- login session 2 (sshd)
\- bash or equivalent
\- CLI applications
\- uid 1001
\- ... similar tree ...
Login sessions 1 and 2, `systemd --user` services, and `systemd --user`
itself can share and use the dbus-daemon, because it is part of a scope
that is "as large as" both of them.
Conceptual model of dbus-x11 without dbus-user-session:
"the system" (system services, etc.)
\- uid 1000
\- systemd --user (if present)
\- non-D-Bus-based user services
\- login session 1 (X11)
\- gnome-session, startkde, ~/.xinitrc or equivalent
\- window manager
\- applications
\- dbus-daemon
\- D-Bus-activated services from login session 1
\- login session 2 (sshd)
\- bash or equivalent
\- CLI applications
\- in principle you could have another dbus-daemon here
if you run dbus-launch manually
\- D-Bus-activated services from login session 2
\- uid 1001
\- ... similar tree ...
Here, login session 1 owns its own dbus-daemon and is the only one that
can see it. `systemd --user` and login session 2 cannot.
The system bus does not have this duality, because there's only one
system bus per system, the same as the init system; so there is no issue
about the init system's service manager role being in a "larger" or
"smaller" scope than the D-Bus system bus.
"uid 1000" and "uid 1001" in the above refer to any uid that currently
has at least one, but perhaps more than one, login session. When I refer
to a "user session" in D-Bus documentation and terminology, this is
what I mean. uid 1000 has a user session; login sessions 1 and 2 are
part of that user session; and so is its `systemd --user`. uid 1001
has a separate user session, containing its own login session(s) and
`systemd --user`. If we imagine uid 1002 exists but does not currently
have any login sessions, then it also does not have a user-session.
I would suggest that dependency system representations for D-Bus services
should probably not be designed by developers for whom the contents of
this message are new information.
smcv
[1] Assuming you have not configured your dbus-daemon with
--disable-traditional-activation at build time; this makes sense for
some constrained embedded systems, which might be Debian derivatives,
but is unlikely to be suitable for a general-purpose distribution
like Debian, and I have no plans to do so.
[2] There are others.
Reply to: