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

[Simon McVittie <simon mcvittie collabora co uk>]

On 05/03/13 21:03, Lennart Poettering wrote:
> My general suggestion is that applications should generally die if their
> display goes away (libX11 already enforces this...).

Right, but that only happens for GUI applications. One of the original
rationales for D-Bus was that it was a way to avoid having stuff like
gconfd still hanging around after the login session had finished
(admittedly, logind's optional cgroup-killing makes that unnecessary,
and is more thorough).

> Having a "gnome-session.service" BTW sounds like a stop-gap though. My
> intention is to move the service management bit of gnome-session into
> systemd (or a generator for it), and then move the rest of it into
> gnome-settings-daemon, and gnome-session would cease to exist

What would "the program whose lifetime defines the GNOME session" be, in
this world?

At the moment things like gdm and startx work like this:

    register the new login session in PAM/logind/etc.
    run gnome-session (or startkde or ~/.xsession or whatever)
    wait for it to exit
    unregister the login session in PAM/logind/etc.
    clean up: put the greeter back up (gdm), terminate the X server
       (startx), or whatever

> > 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  service runs) cannot usefully
> > depend on anything that's a GUI.
>
> Not following here..

Not sure which bit you weren't following, so I'll try to reword both.

The intended design (the one I prototyped) appears to be that logind
runs systemd --user for the lifetime of the XDG_RUNTIME_DIR. If this
lifetime includes any non-graphical login sessions (ssh, tty), then any
session services that are a GUI are just not going to work:

    log in via ssh
    PAM registers a login session
    logind runs my systemd --user [--target default.target]
    default.target wants gnome-shell.desktop.service
    ... not going to work very well.

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

user-session-units contains a session service which starts Xorg. Under
gdm, a $DISPLAY pointing to an existing Xorg instance is "passed in from
outside" (and this is what the logind PAM module expects, in fact), so
that session service is somewhere between useless and harmful.
Similarly, running that service for a ssh login would be rather undesirable!

> > 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'd suggest not to support this. In GNOME I would simply not allow
> multiple local graphical logins of the same user. Instead, the user
> should get a nice box that he is already logged in elsewhere.

gdm currently limits to one login per user *per seat* - I can't "Switch
User" (VT-switching) and log in a second time as myself, but if I had a
USB display/keyboard widget providing a second "seat", I'd be able to
log in on the "main screen" and on that at the same time. The idea is
that each "seat" behaves like a separate computer in terms of input and
output devices. Are you saying that you don't think it should be
possible for a user to be logged-in on both seats?

(Whenever there's more than one local X11 display, gdm itself certainly
needs to be able to put a small GNOME session on behalf of the
special-purpose 'gdm' user on each of them, in order to have the login
screen present, with accessibility and stuff - but maybe it's OK to have
a special case for system users.)

    S