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

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Feb 19 08:06:16 PST 2013


On 18/02/13 20:13, Simon McVittie wrote:
>>> Is there any plan for how GUI processes started via session D-Bus
>>> activation should pick up the right value for $DISPLAY?
>
> 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.

It turns out that this shouldn't be needed, because modern versionx of
Xorg support something like "DISPLAY=unix:/run/user/1000/X11-display" -
so it should be possible to impose this on all processes within the
login1.User. (logind already sets up that path as a symlink or hardlink.)

That isn't going to be particularly graceful if a login1.User has more
than one X11 display. GUI applications that are D-Bus/systemd-activated
*and* want to cope gracefully with this situation will have to do it
themselves, perhaps by accepting a display number from the requester
when it asks them to make a window, and potentially opening windows on
more than one display.

logind's choice of what to link to X11-display is perhaps not perfect
(it will tend to prefer the first X11 display seen, even if that one is
idle), but that can be improved on if/when it becomes a practical problem.

>>> If there is not currently a plan for how to deal with DISPLAY and
>>> XAUTHORITY

XAUTHORITY is not relevant on Linux (i.e. not relevant if systemd
works), because it can be superseded by something like "xhost
+si:localuser:smcv" or the equivalent Xlib calls. GDM already knows how
to do that: for the greeter session, it uses Xlib. For the login session
it certainly runs xhost(1) in the Xsession script, but it might also do
the equivalent Xlib calls internally.

    S


More information about the systemd-devel mailing list