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

[Peeters Simon <peeters simon gmail com>]

2013/2/18 Simon McVittie <simon mcvittie collabora co uk>:
> [...]
> 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.
>
> 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).
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)

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

Display property of org.freedesktop.login1.User?

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

My opinion is that gnome-settings-daemon does to many things.
if we could split out the X11 related stuff (setting the background,...)
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.

in my case (i3wm) it would be something like:

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

and i3  service
[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/i3

For the dbus activation problem we should just monitor the Display
property of org.freedesktop.login1.User and set DISPLAY in the systemd
environment via dbus.

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

Just my 2c

Simon Peeters