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

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

[Desktop Entry]
[D-BUS Service]

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]