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

On Tue, 21.01.14 20:21, Simon McVittie (simon mcvittie collabora co uk) wrote:

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.

An alternative might be to also check $MANAGERPID == getppid() or
so... But yeah at that point it might make sense to go ExecService,

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]

Umpf. Can't say I like that...

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.

Sure, of course this would need to be added to the spec. I'll bring this
up on the dbus ML as soon as we have a rough idea that we actually want
this all...

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

Well, we were just discussing this bit on IRC. 

I'd actually allow as many "login"s per user, per seat, and per machine
as people want. The display manager would merge them all into one big
"xinerama" workspace. However, it obviously makes little sense to log in
twice on the same seat as the same user if this happens, because that
way you could see a some parts of the workspace never at the same
time. Hence, on the lower-level we'd not make restrictions here,
howeber, I'd expect that gdm would not allow this and simply activate
the existing login on the same seat when the user tries to log in
multiple times on the same seat (pretty much the same as it already does
that right now).

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



Lennart Poettering, Red Hat

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