using dbus-run-session....w/X server. how to get DBUS vars?

[Simon McVittie]

On Sat, 24 Nov 2018 at 07:15:06 -0800, L A Walsh wrote:
> when dbus-run-session runs a prog, it makes the session bus available to the
> program, but the rest of the vars are deleted:
> 
>       The variables DBUS_SESSION_BUS_PID, DBUS_SESSION_BUS_WINDOWID,
>       DBUS_STARTER_BUS_TYPE and DBUS_STARTER_ADDRESS are removed from the
>       environment, if present.
> 
> So If I want to use starting my xserver as the start of my
> session, how can I propagate those vars to other processes
> using that desktop?

If you're asking this question, then dbus-run-session is probably
the wrong tool for what you're doing. It's intended for the situation
where you need a temporary, private session bus, most frequently to run
unit tests, and one of these is true:

* you are not already in a D-Bus session
* you are already in a D-Bus session and you don't want the wrapped
  program (unit test) to touch it

The environment variables from "outside" dbus-run-session are removed
when running the wrapped command. In the former scenario, they are not
set anyway, so removing them does nothing. In the latter scenario, their
values refer to the pre-existing session bus "outside" the wrapped
program, so it would be inappropriate for the processes "inside"
dbus-run-session to refer to them.

What is it that you want? The programs you should run depend on the
answer to that question.

If you want one D-Bus session bus for each uid that has one or more
concurrent login sessions, use the `systemd --user` units provided by
dbus, for example the dbus-user-session package on Debian and Debian
derivatives. This setup is the only one supported by some Linux
distributions, including Fedora and Arch Linux (their equivalent of
dbus-run-session is part of the same package as dbus-daemon itself).

If you want one D-Bus session bus per X11 display scoped to the lifetime
of that X11 display, then the right tool is dbus-launch --exit-with-x11
(see dbus-launch(1)). If your OS distribution supports this mode, then
it should really have set up a way to achieve it already, for example in
the dbus-x11 package on Debian and Debian derivatives. It's traditionally
been run something like this:

    startx dbus-launch --exit-with-x11 openbox -- :0
        \- Xorg :0
        \- dbus-launch --exit-with-x11 openbox
            \- openbox                                  [*]
                 \- all other programs                  [*]

    Programs marked [*] inherit the D-Bus-related environment variables
    set by dbus-launch

or like this:

    startx /some/script -- :0
        \- Xorg :0
        \- /some/script
            \- dbus-launch --exit-with-x11 --sh-syntax
            \- openbox                            [*]
                 \- all other programs                  [*]

    /some/script runs dbus-launch first, and evals its output;
    programs marked [*] inherit the D-Bus-related environment variables
    that were set by eval'ing dbus-launch's output

(Or you might be using a display manager like xdm or gdm instead
of startx, but the overall design is essentially the same. Replace
openbox with your favourite desktop environment, session manager or
window manager, for example gnome-session or startkde.)

The deprecated X11 autolaunching mechanism, which is discouraged but
still works, is like this:

    startx some-desktop -- :0
       \- whichever program tried to use D-Bus first
       |   \- dbus-launch --autolaunch      [d]
       |       \- dbus-daemon               [d]
       \- whichever program tried to use D-Bus second
       |   \- dbus-launch --autolaunch      [e]
       \- whichever program tried to use D-Bus third
           \- dbus-launch --autolaunch      [e]

    Programs marked [d] daemonize and keep running. Programs marked [e]
    exit immediately, after reporting the dbus-daemon's address back to
    their caller. X11 selections and window properties are used as a
    crude IPC mechanism to avoid the obvious race condition.

If you want to build your own unique concept of a session (at your own
risk), run the dbus-daemon yourself, probably using its --print-address
and optionally --print-pid options (see the dbus-run-session source code,
the dbus-launch source code, or the dbus, telepathy-glib and Flatpak
unit tests for various versions of code to do this), and propagate the
environment variables to whatever processes you think are conceptually
part of the same session. This is not really something that is
"supported" by anyone, so if you set it up, it's up to you to support it.

It is technically possible to use dbus-run-session to run a desktop
environment something like this:

    startx dbus-run-session -- openbox -- :0
        \- Xorg :0
        \- dbus-run-session -- openbox
            \- openbox                       [*]
                 \- all other programs       [*]

    Programs marked [*] inherit the D-Bus-related environment variables
    set by dbus-run-session

but if you are doing that, you would be better off using dbus-launch
--exit-with-x11, which (unlike this setup with dbus-run-session) also
arranges for X11 autolaunching to be able to work as intended.

    smcv