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

[Kok, Auke-jan H]

On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> 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? Or am I meant to have one 'systemd --user' instance per
> login session, or one D-Bus session bus per login session?

Ideally, we'd have one `systemd --user` survive throughout the entire sequence.

I believe that the DBus bits are properly in place to have one single
user bus per user session.

For each login, you'd have an instance service (e.g.
gnome-session@:0.service) to serve that display.

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

GUI processes running under a gnome-session@:0.service should be able
to getenv(DISPLAY) if it's set by gnome-session at .service
(Environment=DISPLAY=%I).

but yeah, no answer for dbus activated services.

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

even for multiseat?

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

this also seems like it would need to become instanced -
wayland at .service... I looked into wayland earlier and it wasn't ready
for user session integration though - too much stuff in weston
currently breaks right through the user-system separation for it to be
ready for user-sessions.

Auke