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

[Lennart Poettering]

On Mon, 18.02.13 12:38, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

Heya!

(Sorry for the late reply, still fighting against my mail queue after a
week of confs).

> I've recently been researching systemd's current support for user
> sessions, with the goal of sorting out any remaining omissions/issues
> and having GDM integrate well with it.
> 
> It looks as though the intention is that if I have overlapping sessions
> like this:
> 
> * 14:00: log in to GDM on X11 display :0
> * 14:10: log in via ssh or getty or something
> * 14:20: log out from :0
> * 14:30: log in to GDM on X11 display :1
> * 14:40: log out from ssh/getty
> * 14:50: log out from :1
> 
> then from 14:00 to 14:50 I have one XDG_RUNTIME_DIR, one 'systemd
> --user' instance (as per systemd's TODO: started by logind using
> user at .service, on behalf of pam_systemd) and one 'dbus-daemon --session'
> instance (presumably started by that 'systemd --user'). Is that how it's
> meant to work? 

Correct. This is he current plan. The user at .service bit has been missing
so far however.

> Or am I meant to have one 'systemd --user' instance per
> login session, or one D-Bus session bus per login session?

Nope, this is supposed to be per-user, not per-session.

Also, the idea was to allow people to run the session bus if they wish,
but this should be an exotic feature, and in all normal cases the
session bus should be "redirected" to the user bus.

> Is there any plan for how GUI processes started via session D-Bus
> activation should pick up the right value for $DISPLAY (in my example:
> ":0" until 14:20, nothing from 14:20 to 14:30, ":1" from 14:30 onwards)
> and $XAUTHORITY, or is that something that still needs to be solved? Or
> are GUI processes meant to obtain their X11 display and authority file
> in some other way?

$XDG_RUNTIME_DIR/display should be a symlink to the actual socket. But
this is incomplete, as libX11 has not been patched yet. (And also leaves
the question of remote displays unanswered...)

> One simple example of a GUI process started by session D-Bus activation
> is that /usr/bin/gnome-terminal is just a "remote control" which
> activates ${libexecdir}/gnome-terminal-server, a GUI application, and
> tells it to open a new window. This is currently a D-Bus session service
> using traditional D-Bus activation, but it should presumably become a
> systemd user service, with the dbus-daemon handing off activation to the
> user instance of systemd.
> 
> If used in my example above, a gnome-terminal-server started at 14:05
> ought to use display :0, and exit at 14:20 when it loses its connection
> to the X11 server; if I then run gnome-terminal at (say) 14:35, the
> desired result is a new gnome-terminal-server on display :1. If the
> overlapping sessions share a 'systemd --user' and a 'dbus-daemon
> --session', then that would even work if I ran gnome-terminal from the
> text-mode session, which is a nice improvement over how it currently
> works with a session-scoped dbus-daemon (it'd fail because the text-mode
> session either doesn't have a dbus-daemon, or has a dbus-daemon with no
> $DISPLAY).
> 
> If there is not currently a plan for how to deal with DISPLAY and
> XAUTHORITY, I think they could be solved by having 'systemd --user'
> watch logind, and include those variables (or perhaps only DISPLAY?)
> from the corresponding uid's most-recently-started X11 session? (I
> believe GDM only supports one simultaneous X11 session per uid anyway.)
> 
> I don't know much about Wayland, but it appears that it normally has one
> socket "wayland-0" in the XDG_RUNTIME_DIR, and only needs to use further
> environment variables if there's more than one Wayland compositor
> sharing an XDG_RUNTIME_DIR.

In the long run we really should try to get rid of the env var thing,
since that implies serialization. Instead, we should try to use bus
activation and socket activation via $XDG_RUNTIME_DIR wherever possible,
which allows parallel start-up everywhere, and even allows us to handle
nicely that the display in your example changes in the middle of
everything.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.