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

[Simon McVittie]

On 30/01/15 09:30, Simon McVittie wrote:
> user-session
> ------------
> 
> I don't think there is a standard term for this so I'm making one up.

Notes from the hackfest: A few people called these "super-sessions" when
we discussed them. I preferred user-session tbh, but if people want to
standardize on calling them super-sessions that's fine.

> If people want to put work into this model, we could do a lot better
> than we do now; for instance, the bus socket could be
> unix:path=${XDG_RUNTIME_DIR}/sessions/${XDG_SESSION_ID}/bus (but with
> the necessary escaping) on systems where those variables are set, rather
> than messing about with $TMPDIR.

Please open an "enhancement"-severity bug against dbus if you want this,
and I can talk you through the right places to patch; it would not be
rocket science, and if people have use-cases for it, I would be OK with
merging it even though I personally prefer the user-session model.

> Similarly, if you leave a screen/tmux session detached and running
> in the background, systemd is fine with that: its view of the world
> is that there are processes left over from your previous login session,
> keeping the login session alive in "closing" state, with the consequence
> that the user-session remains alive too

Notes from the hackfest: Everyone seems to think screen/tmux/... should
use PAM to register themselves as first-class login sessions in their
own right, if allowed by the sysadmin. That would also work fine.

> Under X11, that might well be the best we can do, because typical
> X11 applications can't cope with being asked to put windows on more
> than one $DISPLAY (although I've heard rumours that Emacs can, which
> would make Emacs an ideal candidate to be a user-session service).
> Under Wayland or similar future cleverness, hopefully there'll be
> some way for a new login on a new seat to "steal" all the windows
> from the inactive seat, or some way to merge both seats into
> one big virtual display if the same person is using both (AIUI this
> is what GNOME designers want to do), or some other clever solution.

Notes from the hackfest: Lennart's long-term idea is to have a singleton
X server (or Wayland equivalent) per uid, and "hotplug" output devices
to it as the user logs in/out on different seats (or remotely via RFB or
whatever), with the ability to clone the same window layout onto all
displays, or have distinct displays and move windows between them, a lot
like the way we currently deal with multiple monitors per seat. This
also solves the $DISPLAY problem rather nicely.

Regards,
    S