[systemd-devel] RFC: user session lifetimes vs. $DISPLAY

[Lennart Poettering]

On Tue, 05.03.13 21:01, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> 
> On 05/03/13 20:10, Lennart Poettering wrote:
> > Well, D-Bus would need to learn about this new [user] bus, and determine the
> > socket in $XDG_RUNTIME_DIR automatically, and also fallback from the
> > session to the user bus if the session bus is not reachable otherwise...
> 
> Do you really want to support both of "user bus == session bus" and
> "user bus != session bus"?

Well, that's a good question actually. Kay actually wants to get rid of
the session bus entirely. My own idea was to use it only for gdm to
support the multi-seat case, where the same gdm user might need to run
multiple gdm sessions in parallel, one for each display. However, that
idea is definitely flawed, and it might be better to fix this for good
and do dynamic user ids or so for this case, so that the gdm sessions
are actually properly isolated from each other...

> With my D-Bus upstream hat on, I doubt we want the complexity (and
> message-ordering-guarantee-breaking) of having parallel
> per-XDG_RUNTIME_DIR and per-login-session buses, and everyone having to
> decide which one their application ought to be on; I predict that having
> the additional oddity of "they are logically distinct, but might really
> be the same bus, or not" is going to cause bugs.

Well, our idea was that if people ask for the session bus, they'd
actually get the user bus. That would mean only for the gdm case people
would actually have to think whether they really want the session or the
user bus, since for all other cases requesting either would actually get
you on the very same bus...

> If you're determined that a per-user bus is a good thing to have, then I
> think I'd prefer "DBUS_SESSION_BUS_ADDRESS points to the
> per-XDG_RUNTIME_DIR bus if there is one, or the per-login-session bus
> otherwise", with the two mutually-exclusive (with the former situation
> being mainly a "new systemd thing", and the latter situation being what
> you get on current Linux systems). It wouldn't be the first time that
> systemd has declared "these semantics are what we support, nothing else
> really worked anyway"...

Yeah, this is an option.

I mean, to make this clear: one of the reasons I so far never finished
this in detail, was that we were a bit unsure about hte best approach
here. I kinda hoped that revisiting this after a year would magically
have solved this, and we'd know now what way to got, but as it turns out
I am still unsure.

> There's a D-Bus bug where I proposed patches for a new 'xdg-runtime:'
> transport which looks for a Unix socket in XDG_RUNTIME_DIR, with the
> intention that the libdbus default could eventually change to
> "xdg-runtime:;autolaunch:", i.e., look in XDG_RUNTIME_DIR first; or if
> there isn't a socket there, it must be a non-systemd system, so use the
> traditional X11 autolaunching. Or, if you really really want both user
> and login-session buses, "xdg-runtime:" could be the default address for
> the user bus.

This sounds very useful.

> The thread on per-user vs. per-login-session buses on the dbus list a
> couple of years ago raised various concerns, but never really came to
> any conclusion, unfortunately.

Yeah, we really should figure out what we want here. I mean, I am happy
with breaking some setups, but so far, our case isn't fully sound yet.

Anyway, let's try to summarize our status quo:

a) systemd knows only --user, i.e. a per-user instance. 

b) D-Bus knows only a --session, i.e. a per-session instance.

And here are our options:

1) Drop systemd --user, and go back to dbus --session.

2) Add dbus --user, and keep it separate from --session, i.e. thus
   confusing developers with three distinct busses.

3) Same as 2) but do actually keep it separate only for the gdm case,
   otherwise redirect --session to --user.

4) Introduce --user, and always redirect --session to it. This way
   --user would be pretty much identical to --sessin, except for where
   the socket is stored and how it is communicated.

Approach 4 is the arguably the "cleanest one", but current gdm is
incompatible with it.

I really don't wan to go back to 1), or do 2). So in my eyes the choice
is between 3) and 4). Or are there other ideas, anyone?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.