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

[Simon McVittie <simon mcvittie collabora co uk>]

On 19/02/13 23:55, Peeters Simon wrote:
> or just use a systemd generater to generate systemd .service files from the
> dbus service files.
> (i have something like this laying around slightly unfinished if you
> want code, let me know)

That would be an interesting way to avoid having to either patch every
single D-Bus session service (there are rather a lot of them!) to have a
systemd unit, or have `dbus-daemon --session` implement the same
display-tracking as `systemd --user`. Could you publish this somewhere,
please?

> > 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.
>
> Display property of org.freedesktop.login1.User?

Indirectly, yes. User.Display is the (ID and) object path of a
login1.Session, and that Session's Display property is the X11 display
we actually wanted.

In the systemd patches I'm trying out, I'm actually planning to use
libsystemd-login (= inotify on files in /run), because systemd's D-Bus
code is mostly geared towards being a service rather than being a client
of an external service; listening for those signals without a
vulnerability equivalent to CVE-2013-0292 would basically require
reinventing GDBusProxy (track the owner of the o.fd.login1 name, ignore
signals not from that owner), and that's a lot of code for what ought to
be a simple task.

> My opinion is that gnome-settings-daemon does to many things.

I'm sure it does; but the more changes get added to the critical path,
the longer it will take to make them all, agree with the various
projects' maintainers that they are the *right* changes, and get them
all landed.

I do notice that gnome-settings-daemon isn't D-Bus-activatable - it's
currently run as an "application" by gnome-session, which will
presumably remain a one-per-DISPLAY thing - so it might be OK to have
several g-s-d instances queueing for the org.gnome.SettingsDaemon name,
and have each of them additionally take an "instanced" bus name like
org.gnome.SettingsDaemon._3a0 or something?

> we could use a little wrapper binary that tracks the users sessions, and
> launches an instantiated service for each new display, so that all  X11 stuff
> (window managers included) runs once per DISPLAY but the other services run
> once per user.

I'm not at all sure that window managers should be a systemd service. My
understanding is that window managers that aren't part of a larger
"desktop environment" generally act as the main process run by xinit or
gdm or whatever, whose lifetime defines the lifetime of the X session?
(So, the same role as gnome-session.)

> i3.service:
> [Service]
> ExecStart=/usr/libexec/systemd-foreach-display --user i3  service

This seems to assume that you always have one or more displays? Unless
systemd-foreach-display is actually a daemon...

> The only thing blocking this for now is that systemd does not appear
> to send PropertyChanged signals for this property.

This can currently be worked around by monitoring PropertyChanged for
Sessions, I think - the Display can't change unless either there is a
new login session with an X display, or an existing login session with
an X display has gone away.

    S