GNOME.org
 

Re: Hooking up gnome-session with dbus/kdbus/systemd

On Tue, 21.01.14 19:49, Giovanni Campagna (scampa giovanni gmail com) wrote:


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.


Interesting, last I tried I had crashes all over the session, and bus
activation was not working...


Yeah, it took a while to stabilize but it should just work on Fedora,
after making the change from Kay's mail in
/etc/X11/xinit/xinitrc.d/00-start-message-bus.sh.


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.


This won't work, because the Exec line from .service has a different
purpose than the Exec line from .desktop: the first runs the service,
the second activates the application provided by the service (ie, it
opens a window)
For example, gnome-weather's service runs
/usr/share/org.gnome.Weather.Application/org.gnome.Weather.Application,
which is a DBus service that does nothing, while gnome-weather's
desktop runs /usr/bin/gapplication launch
org.gnome.Weather.Application, which sends a message on the bus
telling the service to open a new window and quits.
Similarly, gnome-software's desktop runs /usr/bin/gnome-software,
which is an old style application with a window, no fancy dbus stuff,
while the service runs /usr/bin/gnome-software --gapplication-service,
which just runs idly until it gets a DBus message to open the window.
So we would need a new line, ExecService=, that has the same purpose
as the Exec= key from service files.


Well, this seems unnecessary. And app should just check for
$DBUS_STARTER_BUS_ADDRESS or $DBUS_STARTER_BUS_TYPE. If that is set it
is bus actviated. If it isn't it is not. In the latter case it should
pop up a window.


Additionally, many session bus services are not applications at all,
and installing a desktop file (which would be picked up by the shell,
increase our caches and confuse our tracking) would be conceptually
wrong them.


Sure, most of the .desktop files from /etc/xdg/autostart aren't apps but
background services. The standard NoDisplay= field should be set for
these. I think the current desktop file spec covers this neatly already.


Finally, systemd has a generator for .service files, it hasn't got one
for .desktop files, so why pushing for deprecating .service?


Because it appears redundant and complex. And especially with a
perspective of sandboxed apps I'd like to minimize contact points
between apps and the host to a minimal number.


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.


To be precise, gnome-software, polari, gnome-clocks do as well.
gnome-sound-recorder could be switched easily too (because it uses
gnome-weather's infrastructure).
OTOH, I have a gnome-weather branch that replaces the .service file
with .busname and .service units, which would be nice because I would
get proper starting and stopping, and the ability to be started not
just by busname but also at session start (for a background service
polling NWS advisories).


Well, but you could get all of this with .desktop files too, if systemd
understood them natively.

(Not saying that you shouldn't ship native systemd unit files, there are
many reasons one might still want to do that, since it opens up so many
additional settings...)


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.


Well, at least in the interesting cases (gnome-shell and
gnome-settings-daemon), gnome-session hooks the phase logic to an
explicit notification, through XSMP for gnome-shell and through DBus
for gnome-settings-daemon.
The dependencies for the three components are quite complex
(especially as the order is reversed in the X11 and Wayland sessions),
so I'd rather not touch that, and keep "gnome-session + gnome-shell +
gnome-settings-daemon" as a unit.
Everything else could be hooked to bus - except for legacy XSMP
semantics that we need to preserve...


Hmm, do we actually really want XSMP still? This has come up a couple of
times already in the past, isn't it time to finally let it go?

I'd really prefer if mutter/gnome-shell and gnome-settings-daemon would
be forked off systemd. To explain this, a bit more about the bigger
picture regarding sessions and seats and the user bus:

I'd expect that the display manager (at least in a Wayland world) would
be something that is started when the user first logs in and then stays
around until he last logs out, grabbing all devices attached to the
seats of the sessions of the user as the user logs in and out. i.e. I'd
like to see the display manager as a per-user singleton that manages not
just one session but everything that pops up for the user it runs under
and merges this into one big xinerama-style display. Or in other words:
if the same user logs into two local seats he would get a single
gnome-shell that spans all seat's displays. (optionally, the user could
also move this to "clone" mode, as he already can).

As David Hermann just assured me on IRC me something like this is not
too hard to make work for both Wayland and X11 actually. Now with that
in mind, gnome-shell/mutter/wayland would be started when the first user
session is created, and would stay around until it sees that the last
session is gone. If we instead ran it as part of a specific user session
then it would go away as soon as that one session died, which is less
desirable...

Lennart

-- 
Lennart Poettering, Red Hat
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]