On Thu, 31 Oct 2019 at 21:23:54 +0100, Thomas Koch wrote: > `man 5 environment.d` describes a mechanism to set environment variables for > the global and user-session systemd instance. > > However when dbus-x11 is installed, the user session environment defined in > the above way is overwritten by > /etc/X11/Xsession.d/95dbus_update-activation-env
This is done because various packages rely on being able to set environment variables in /etc/X11/Xsession.d and have them inherited by "all" user processes. It's a backwards-compat compromise that I wish wasn't necessary. If we could rely on environment.d, then packages wouldn't have to set environment variables in /etc/X11/Xsession.d, but then they wouldn't work in non-systemd environments. The reason why this backwards-compat mechanism is in dbus-x11 (and not dbus-user-session) is in the hope that systems that rely on systemd --user and environment.d can eventually remove dbus-x11. > https://bugs.debian.org/833318 suggests that the --systemd option does not > work anyways. Do you have evidence that the attempt to call SetEnvironment() does anything (whether desired or not) when not using dbus-user-session, or are you reporting this bug on the basis that if it worked, it would have a result that you don't want? My understanding is that it doesn't have any effect (good or bad) when not using dbus-user-session, because when not using dbus-user-session, systemd --user is not aware of the D-Bus session bus and is not connected to it; this means it can't be controlled with D-Bus session bus method calls like SetEnvironment(). The purpose of dbus-user-session is that it selects the mode of operation where there is only one D-Bus session bus per uid, which makes it reasonable for the one-per-user systemd --user to connect to that single session bus and make itself available to be controlled by session bus method calls. If you have chosen to purge dbus-user-session and use dbus-x11 instead, then the same uid can have multiple D-Bus session buses, but there is still only one systemd --user per uid. It can't possibly have the right value of DBUS_SESSION_BUS_ADDRESS for all of them, and it seems reasonable to me that it doesn't get the Xsession.d environment variables from any of them? This is the same thing that always happened before dbus-user-session was added. If you are using dbus-x11 and not dbus-user-session, then D-Bus-activated session services are all children of dbus-daemon --session, not children of systemd --user; so they get their environment variables from dbus-daemon's UpdateActivationEnvironment(), not from systemd's SetEnvironment(). (This might mean they're different.) Complicating matters further, if you are using dbus-user-session, the dbus-daemon also responds to UpdateActivationEnvironment() calls by forwarding the same environment variables to systemd's SetEnvironment(). This is to avoid breaking programs like gnome-session, which expect that they can call UpdateActivationEnvironment() to set the given environment variable for all user services, when session services get converted into systemd --user services. Again, as far as I'm aware, this won't/can't work if you are not using dbus-user-session, because in that case systemd is not present as a session bus service. (We kept --systemd anyway, because it can matter in rare corner cases involving environment variables whose values are not UTF-8 - the dbus-daemon's API cannot represent those, but systemd's can.) > Maybe it makes sense to go to the drawing board and check how > environment variables are set right now in dbus, systemd and the session > leader process and how we think it should be. - Any prior art here? I'm open to suggestions. >From past experience, pinning down what the desired semantics even are is likely to be difficult; doubly so when making them work for all three modes, with different expectations and constraints for each: - session bus per X11 session, not using systemd - session bus per X11 session, using systemd (you are here) - session bus per systemd --user (this is dbus-user-session) I usually recommend dbus-user-session, which has a reasonably coherent model for what is in a session and how it communicates; but it isn't the model that everyone wants (multiple X11 displays for one uid are the usual problem area), which is why it isn't mandatory in Debian, unlike e.g. Fedora and Arch. smcv
