Hooking up gnome-session with dbus/kdbus/systemd

[Lennart Poettering <mztabzr 0pointer de>]

Heya,

I am typing this from a GNOME session that actually uses a kdbus user
bus instead of a dbus-daemon session bus (and also a kdbus system
bus). With this mail I'd like to start discussion of the changes I'd
like to propose for GNOME to make this work a bit more smoothly.

As you might now, the kdbus userspace we have been working on involves
using systemd for setting it up. The system systemd instance will set up
the system bus, and the user systemd instance will set up the user
bus. Besides actually opening up kdbus for usage in the session bus, I'd
also like to see GNOME adopt systemd for its process (application)
management needs. This would have a number of benefits, like for example
exposing GNOME apps (and other components) as cgroups, so that we can do
all kinds of modern stuff like suspending apps that our outside of view,
or fiddling with the CPU scheduling prio for foreground apps, and things
like that. Also, we'd gain a trustable, kernel-level way how to
distuingish apps, for polkit stuff and more.

Now, systemd is not available on all systems GNOME supports, so we
should find a way that neatly hooks this all up with systemd, but
doesn't make systemd a hard-coded dependency of GNOME. Of course, the
internets will never honour our attempt at being nice here, but we
should try anyway... ;-)

So, the way I'd like this all to work is by simply emphasizing .desktop
files and bus activation a lot more, without actually emphasizing
systemd as backend implementation of anything. As both technologies
(.desktop files and dbus) are universially supported wherever GNOME is
supported this should be a good approach:

a) I'd like to see native D-Bus ".service" activation files deprecated
   in dbus. Instead, for the user/session bus, I'd like to see
   everything moved to .desktop files. Ryan recently extended the
   .desktop spec for declaring bus names in .desktop files so that
   applications no longer need to be forked off directly, but can simply
   be bus activated. I'd like to take this one step further:
   dbus-daemon/systemd should just read the .desktop files directly, and
   use this information for maintaining its own activation lists,
   so that we keep everything at one place, instead of two. Note that
   currently the .desktop file spec says that either Exec= is honoured
   or the thing is bus actviated; it would be only a minor addition to
   say that the bus activation on the bus manager side can actually
   happen with the Exec= line, too. (As a side note, not directly related
   to GNOME: on the system level I'd like to see D-Bus ".service"
   activation files deprecated too, in favour of the native service
   definition files of the respective init system of the distrbution,
   regardless whether it might be systemd or Upstart or whatever
   else). Of course, support for the old .service activation files will
   be kept for a while for compat.

b) The other side of the medal than is that all GNOME programs should
   ship with .desktop files that include bus activation bits. Currently
   gnome-weather is the only one that does. I'd like to see the bus
   activation stuff to be the rule, not the exception.

c) gnome-session currently has some special .desktop file support that
   it uses to set up the session and run it (parsing stuff from
   /etc/xdg/autostart). For that it forks off all
   processes on its own, and will wait for SIGCHLD to bind the lifecycle
   of the session to the lifecycle of gnome-settings-daemon +
   gnome-shell. It also uses that to implement "phases". I'd like to see
   this minimally changed to watch for the
   existance of the respective bus names instead, and use normal bus
   activation to start everything. The phase logic can stay in
   gnome-session even if gnome-session doesn't fork anything of
   anymore but uses bus activation for everything. The hookup that these
   desktop files have with dconf would also stay unmodified.

d) I'd like to see gnome-session to push $DISPLAY and $XAUTHORITY as
   environment variables into the bus manager. This makes things nicely
   work when a per-user bus is used rather than a per-session bus. This
   would have no effect if dbus-daemon is used in session mode, but a
   big effect if systemd is used in user mode. (Note that
   gnome-session/gnome-settings-daemon already push quite a few env vars
   already, so this would just be two more...)

The great thing about this approach is that GNOME basically doesn't have
to know anything about systemd, yet we get everything nicely exposed as
systemd service. It will just use dbus APIs, and dbus will adopt standard
.desktop files as its configuration source. Whether the actual dbus
implementation used is dbus-daemon or systemd+kdbus is irrelevant to
GNOME. (Well, with one exception: to support apps that do not use the
bus but do ship a .desktop file, for example games and suchlike, it
would probably make sense if GNOME would try to actviate this via
explicit systemd calls rather than forking off directly. But that should
be easily doable in a safe way that doesn't add a strict dependency to
systemd).

To me at least this all sounds reasonably simple and straightforward. I'
like to begin this discussion here on the GNOME ml for now. If we have
some form of agreement I'll involve the xdg + dbus mailing lists too, i
figure the other desktops want to be kept in the loop for this too, as
they are in a very similar situation in probably wanting to use systemd,
but not as struct dep.

On the systemd side the only missing bit here is to teach it native
support for .desktop files. But that shouldn't be too hard.

On the GNOME side the missing parts are making everything actually use the
bus activation bits in .desktop files, which might be a bit more work
covering a lot of individual components, since it also means exposing
the dbus interfaces Ryan defined (GtkApplication...). And then
gnome-session would need to push one more var, and be able to track its
services not by PID+SIGCHLD but by bus names.

Does this make sense? Suggestions? Ideas?

Lennart

-- 
Lennart Poettering, Red Hat