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

[Dimitri John Ledkov]

On 30 January 2015 at 08:30, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> Remaining issue: environment variables
> ======================================
>
> Sadly, not all the issues have been resolved yet. The biggest is
> environment variables: on existing systems there is an expectation
> that environment variables set by *dm, PAM, or /etc/X11/Xsession.d
> (or the non-Debian equivalent) will be propagated into every process
> in the session. In a brief survey of about half the Xsession.d scripts
> in Debian, I identified these environment variables:
>
> * PULSE_SERVER
> * ESPEAKER
> * XDG_DATA_HOME, XDG_DATA_DIRS
> * each variable printed by locale(1)
> * VDPAU_DRIVER
> * GTK_IM_MODULE, QT_IM_MODULE, QT4_IM_MODULE, CLUTTER_IM_MODULE,
>   XMODIFIERS
> * GTK_MODULES
>

And one shall not forget GNOME_DESKTOP_SESSION_ID=this-is-deprecated
for a certain C++ toolkit to not look like it's 1995. ;-)

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

Looking at the stuff that I have on my session dbus, I see quite a few
things that do interract with DISPLAY=:0, or rather create GUI windows
and expect them to appear in the right place, as in on the currently
active seat. Similarly they would need to be migrated/restarted if we
ever allow multiple graphical search for a single UID. 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)).

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). That
means that dbus-activated services have to simply become seat aware,
and know that if they were started on a non-graphical seat, later on
active seat might be graphical and thus they should
migrate/recreate/create GUI windows on currently active seat - or
across all seats if that's appropriate.

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.