[systemd-devel] RFC: user session lifetimes vs. $DISPLAY
simon.mcvittie at collabora.co.uk
Wed Feb 20 01:42:33 PST 2013
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,
>> 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
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.)
> ExecStart=/usr/libexec/systemd-foreach-display --user i3 at .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.
More information about the systemd-devel