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

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Mar 5 13:01:37 PST 2013

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"?

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.

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"...

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.

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.


More information about the systemd-devel mailing list