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

[Kok, Auke-jan H]

On Mon, Feb 18, 2013 at 12:13 PM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> On 18/02/13 19:08, Kok, Auke-jan H wrote:
>> On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie
>> <simon.mcvittie at collabora.co.uk> wrote:
>>> It looks as though the intention is [...]
>>> 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').
>>
>> 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.
>
> To be completely clear: what exactly do you mean by "per user session"
> here? Is a "user session" a login1.Session, or a login1.User?
>
> If I upstream the dbus.service, dbus.socket from user-session-units into
> dbus, then we have exactly one `dbus-daemon --session` per `systemd
> --user`. If one `systemd --user` spans the whole lifetime of a
> login1.User, that's one `dbus-daemon --session` across one or more login
> sessions:
>
>            :0                          :1
>       -------------   /dev/tty1   -------------- X login session
>               --------------------------         getty login session
>       ========================================== XDG_RUNTIME_DIR
>        ========================================= systemd --user
>         ======================================== dbus-daemon --session
>
> (In that diagram, ---- is login1.Session-scoped, ==== is
> login1.User-scoped.)
>
> I don't think it's particularly useful to do that upstreaming until we
> have a reasonable answer for how DISPLAY gets copied around.

right

> logind doesn't currently track XAUTHORITY alongside DISPLAY, but perhaps
> it should (or perhaps GDM should always put users' Xauthority databases
> in their XDG_RUNTIME_DIR).
>
>> For each login, you'd have an instance service (e.g.
>> gnome-session@:0.service) to serve that display.
>
> I'm not sure how much that would actually help. GDM and other display
> managers currently consider the lifetime of the session to be defined by
> the lifetime of a process (which, for GNOME, is gnome-session). In
> principle it would be possible to make that process be "start
> gnome-session@:0.service on the user systemd, and when it exits, exit",
> but I'm not sure that really gains us anything over GDM just running
> gnome-session! It seems more useful to get session D-Bus services
> systemd-activated, then use those whenever possible (so that systemd
> --user can run them on-demand, perhaps starting as soon as the PAM
> session opens).
>
> The next step might be to have a way for XDG applications (.desktop
> files) - or at least those that are one-at-a-time-per-user - to be
> systemd-activated, so that application launching happens through the
> user systemd.
>
> Having a `systemd --user` survive across multiple sessions does conflict
> with user-session-units' current assumptions: it would imply that
> default.target (or whatever target user at .service runs) cannot usefully
> depend on anything that's a GUI. xorg.target would also have to change
> (cope with an X11 display being passed in from outside the session, or
> be instanced, or something), but that's true for GDM anyway.

right - that's painfully obvious as we define the instance of the
session based on the UID.

>>> Is there any plan for how GUI processes started via session D-Bus
>>> activation should pick up the right value for $DISPLAY?
>>
>> 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).
>
> I thought the idea of `systemd --user` was to reduce the set of
> processes running under (as in child processes of) gnome-session,
> ideally to 0? :-)

I have obviously not thought this all out...

We may have to redefine systemd --user to start with a instance that
defines a "user - seat" pair instead. That would leave multiple
`systemd --user` pairs around, each serving the appropriate desktop.
They could use a central DBus location if needed, share agents and
such. Each would however run with DISPLAY hard set to the right
display number, would that be an improvement?

>> but yeah, no answer for dbus activated services.
>
> I've started prototyping what would be needed for `systemd --user` to
> track logind sessions, pick up the new $DISPLAY every time the user's
> set of sessions changes, and use that for all new activations.

this implies that services re-connect to the new display in case it
changes, or better, services hangup when no longer in use in order to
prevent to a nonexistant display.

> If not every session D-Bus service is a systemd user service, then
> dbus-daemon would need to do more or less the same (but in any case, the
> goal ought to be that every session D-Bus service is also a systemd user
> service, I think).

agreed, that would be ideal.

>>> 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?
>
> No, you're right, it's one per (uid, seat) pair. So for multi-seat
> setups there'd certainly have to be some concept of "best X11 display"
> (most recently started?) in the environment of new activations.
>
> I wonder how much breaks when two X11 displays share a session bus? For
> instance, gnome-settings-daemon takes a well-known name on the session
> bus, but does various X11-centric things...

ultimately this behavior will break, or it itself will have to be
broken in two parts.


Auke