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

[Peeters Simon]

2013/2/20 Simon McVittie <simon.mcvittie at 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?

finished it up for you.
https://github.com/SimonPe/systemd-dbus-generator

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

I don't know a lot about g-s-d, but it should be a possible solution.

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

maybe, but this would create a split between the window manager and
the rest of the session. It would also mean that one can not use
systemd features like Restart=always and maybe even the systemd's
watchdog system, to simplify there failover policy.
Having the window managers as services also allows us to use a system
similar to the display-manger.service, and to switch window managers
while keeping the session. (systemctl --user stop i3.service &&
systemctl --user start gnome-shell.service)

>> i3.service:
>> [Service]
>> 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 systemd-foreach-display would be a daemon monitoring the logind
sessions, starting new instances when new graphical sessions appear,
and stopping instances when there session disappears. (note that this
is still purely hypothetical)

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

I might even have some time during next week to see if i can write
something like this.
>
>     S

the other S