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

[Simon McVittie <simon mcvittie collabora co uk>]

On 21/01/14 19:22, Lennart Poettering wrote:
> On Tue, 21.01.14 19:49, Giovanni Campagna (scampa giovanni gmail com) wrote:
> > 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)
...
> > 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.

No, that doesn't work; child processes of an activated process will
inherit DBUS_STARTER_* from it, but should normally be starting in
"interactive, pop up a window" mode. For instance, run gvim from
gnome-terminal, then look in /proc/`pgrep gvim`/environ - the actual
terminal bit of gnome-terminal is an activated service.

libdbus used to try to remove these variables from the environment so
that the activated process' children wouldn't get them, but this was (a)
not thread-safe, and (b) broken for several years with no apparent harm
done (the names of the variables were changed years ago, but the code to
remove them wasn't updated to the new names), so we removed the
offending code.

If you want the protocol for activation to involve testing these
variables, then it would need to include a variable with the pid of the
process that is expected to obey those variables, similar to the systemd
LISTEN_FDS/LISTEN_PID protocol - but to be honest I think ExecService
might well be a nicer way to do this anyway.

Possibly slightly silly idea: desktop files are .ini-style, D-Bus
services are .ini-style, so a file containing both would not be
unreasonable...

[Desktop Entry]
Name=Terminal
...
TryExec=gnome-terminal
Exec=gnome-terminal
Icon=utilities-terminal
Type=Application
...
[D-BUS Service]
Name=org.gnome.Terminal
Exec=/usr/lib/gnome-terminal/gnome-terminal-server

Using .desktop for service-activation is a nice idea, although for it to
be merged, I'd want to have some D-Bus Specification text and a
regression test.

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

When you say "session" here do you mean in the PAM sense: thing that a
user can have more than one of at a time, all sharing a "systemd --user"
if in use?

AIUI, we have traditionally had:

* one session dbus-daemon per "login"
* one (gnome-shell, gnome-settings-daemon, ...) per "login" (if X11)

and you're proposing:

* up to one (user bus, systemd --user) per (user, machine) at a time
* up to one "login" per (user, seat, machine) at a time,
  potentially several sharing a systemd --user
* one (gnome-shell, gnome-settings-daemon, ...) per systemd --user
  (if at least one "login" is X11 or Wayland)

where by "login" I mean situations like "user sits down at a gdm prompt
and types in their password" or, if you're @1990sLinuxUser, "user logs
in on a tty and runs startx".

    S