[systemd-devel] User sessions, session buses, user buses

[Simon McVittie]

On 02/02/15 10:22, Dimitri John Ledkov wrote:
> I would like to experiment with a user-bus, potentially in a transient
> manner to have 3 buses: system, user, session busses.

I still think it's a bad idea to have both a user bus and a session bus.
Having things "on the wrong bus" is definitely an API break, and having
processes' messages be out-of-order will break application expectations
(message order is guaranteed to be a consistent "total ordering" within
one bus, but you can't even rely on "causal ordering" across multiple
buses).

> E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user
> bus, things should know how to start talking to Telepathy/dconf over
> user bus.

If you have both buses, this is a flag-day API break for each thing that
moves. Please don't go there if you want to reach a user bus in a finite
time.

If you only have a session bus, where "session" is taken to mean either
login session or user-session/super-session depending on a choice made
by the OS integrator and/or sysadmin, you don't get that problem.

> I wonder if
> this is at all an actual problem, maybe all current/sophisticated
> dbus-heavy DEs cannot in fact have multiple graphical sessions for the
> same UID, in which case switching to user bus today is non-regressing
> (given that current active graphical session cannot migrate a seat (?!
> not sure if this)).

GNOME (at least, if you have the full GNOME suite including gdm)
specifically does not support more than one graphical session per seat:
if you are logged in (with screen locked) on tty7, and you type your
username and password into a "Switch User" gdm prompt on tty8, gdm will
just switch to tty7 and unlock your screen. I think this is a perfectly
reasonable model. I don't know about multiple seats as the same user,
but I suspect that, in practice, it doesn't work very well (if at all)
and in any case, why would you? You are only physically in one place
after all :-)

I believe the situation last time we discussed this was that KDE does
support more than one simultaneous graphical session, but Thiago was
unsure whether that was by policy or coincidence.

> Going down this rabbit-hole, the only difference between current
> session-bus (e.g. where under gdm only one graphical login is allowed
> per UID) and the user-bus seems to be the life-time of the bus (tied
> from first login until last login V.S. X11 started and finished).

Yes. This is part of the reasoning behind the mental model that Havoc
proposed last time this was discussed: this is not about the D-Bus
maintainers deciding how long a D-Bus bus lasts, but about OS
integrators deciding how long a session lasts (or to put it another way,
which of the multiple possible definitions of session should be the one
used for D-Bus).

When you think of it like that, the decision point becomes whether the
OS integrator wants:

* dbus-launch manages one session bus per X11 session (current
  reality, and apparently some people strongly prefer it this way)

* dbus.socket/dbus.service manages one session bus per
  user-session/super-session (I anticipate that e.g. Fedora and
  GNOME-Continuous will probably make this simplification mandatory)

* punt the decision to the sysadmin via whether an optional
  dbus-user-bus.deb, or RPM equivalent, is installed (I suspect I will
  have to support both ways for Debian for a while)

Over time, as GUI things adjust to the 'systemd --user'-style model, I
anticipate that the disadvantages of the user-session bus will decrease
and its advantages will increase; maybe one day nobody will use
dbus-launch and it can be deleted.

    S