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

[Lennart Poettering <mztabzr 0pointer de>]

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

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

> 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

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

Yes.

> AIUI, we have traditionally had:
>
> * one session dbus-daemon per "login"
> * one (gnome-shell, gnome-settings-daemon, ...) per "login" (if X11)

Correct.

> and you're proposing:
>
> * up to one (user bus, systemd --user) per (user, machine) at a time

Correct.

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

Correct.

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

Yupp.

Lennart

-- 
Lennart Poettering, Red Hat