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

Lennart Poettering mzqohf at 0pointer.de
Mon Feb 2 14:16:24 PST 2015


On Mon, 02.02.15 10:22, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

> > plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly,
> > a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR,
> > EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others.
> >
> > The naive implementation would be to run a tool at the end of
> > /etc/X11/Xsession.d that uploads all of these into `dbus-daemon
> > --session` (if used) and into `systemd --user` (if used). However, not
> > all environment variables set in such scripts are suitable for that use:
> > notably, XDG_SESSION_ID from the login session should not be copied into
> > activated processes that exist outside any login session.
> >
> 
> The rest of the email thread is adequate.
> 
> I would like to experiment with a user-bus, potentially in a transient
> manner to have 3 buses: system, user, session busses. And migrate
> things from session to user bus & experiment as to how much stuff
> breaks. I think being explicit about session vs user bus would avoid
> confusion, and will help manifest bugs & have a clear migration plan.
> 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.

I'd be very careful with running things with three instead of two
busses, since most user services only open one bus connection, and
they assume they find all the user's services on that one
connection. If you now intrdouce a seperate user and session bus, you
will have to patch all those apps to keep connections open to both
busses, and individually check for each bus call they make which bus
they need to do that on.

I am pretty sure the going for 3 busses, instead of 2 is not worth the
effort and much much more work than just redefining "session" to
"user", the way we currently try to do in the kdbus context.

Note that we test this per-user bus daily, since its the default mode
of operation if you boot with kdbus turned on. For that, simply build
the kdbus kernel modules as well as systemd with kdbus. Then boot with
"kdbus" on the kernel cmdline and all should be good. We now ship with
all the necessary bits in systemd git to make this just work.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the dbus mailing list