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

[Lennart Poettering <mztabzr 0pointer de>]

On Tue, 05.03.13 21:24, Simon McVittie (simon mcvittie collabora co uk) wrote:

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

Well, but gconfd is actually a service that should live from the first
login to the last logout, and then be killed. Since it doesn't connect
to the display, this is exactly what would happen with our approach:
the systemd --user instance would just take it down when you last
logout, and that's it.

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

Well, nothing really. My idea is more or less that when you login you
get a couple of services started on the bus, and they either die as soon
as the display goes away, or stay around until you finally logged out,
and that'd be it.

> 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

Well, we'd probably just have a small tool that checks if there's
already a GNOME session around, and if so, complains about that nicely
graphical, and otherwise just tells the user systemd to spawn
gnome.target or so, and this would pull in everything that needs to be
there for the GNOME session. This tool would then also watch the
display, and simply exit when the display goes away.

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

Correct.

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

Nah, gnome.target would be pulled in by the graphical login thingy (see
above).

Desktop environments which actively want to support multiple
simultaneous graphical logins by the same user could pull in
myde@:1.target or so, and go the instantiation route.

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

Yes, xorg.service is something that makes no sense for the general GNOME
solution.

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

Yes, that's what I am saying. No local simultaneous graphical logins by
the same user, regardless if on the same seat or different 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.)

Yeah, gdm is special, but as mentioned the right way to handle this is
probably to have dynamic users for this, which can be allocated, which
can't write to disk, and which go away whe the login screen ends.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.