[systemd-devel] RFC: user session lifetimes vs. $DISPLAY
Peeters Simon
peeters.simon at gmail.com
Tue Feb 19 15:55:28 PST 2013
2013/2/18 Simon McVittie <simon.mcvittie at 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 at .service
and i3 at .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
More information about the systemd-devel
mailing list