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

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 18.02.13 20:13, Simon McVittie (simon mcvittie 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 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  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:

My original idea would be to have one user dbus.service + dbus.socket
for each user session that is run from the user systemd, and invokes
dbus-daemon --user. Of course, "dbus-daemon --user" doesn't exist
now... (see other mail).

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

My general suggestion is that applications should generally die if their
display goes away (libX11 already enforces this...).

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, but I am
a bit speaking out of my ass here, since I didn't actually look in
detail what gnome-session currently consists of in detail.

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

Yeah, I would like to see an generator in systemd that converts XDG
.desktop files into systemd units. This should probably be a written in
GLib, to get the GNOME .desktop file parser into place. Genreally we are
a bit careful with glib code in PID 1 (due to OOM), but the nice thing
here is that generators are run out-of-process, so this should be fine.

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

Not following here..

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.