Activation environment(s)?

[Simon McVittie]

On Mon, 08 Jan 2024 at 20:42:54 +0300, Vladimir Kudrya wrote:
> On 08/01/2024 19.21, Mantas Mikulėnas wrote:
> > The traditional dbus-daemon keeps a separate environment for services it
> > spawns directly [...], though that it doesn't apply to services it runs
> > via systemd so you need to keep both in sync.

Actually, when you call the dbus-daemon's UpdateActivationEnvironment(),
dbus-daemon >= 1.10.4 will try to upload the same variables to both
dbus-daemon and `systemd --user`, keeping both environments in sync.

`dbus-update-activation-environment --systemd` will also try to upload
the same variables to `systemd --user` (which is redundant since 1.10.4,
but it does it anyway, because it doesn't know whether the message bus
it's talking to has this behaviour).

I say "try" because in some corner cases, for example non-UTF-8 variable
names or values, systemd and/or dbus-daemon will reject particular updates
as not being valid.

As far as I know, the other way round is not true:
`systemctl --user set-environment`, `systemctl --user unset-environment`
and their implementation UnsetAndSetEnvironment() will change the systemd
activation environment, but will not do anything to the activation
environment used by dbus-daemon for traditional D-Bus services (without
SystemdService).

> Is it possible to unset a variable from native dbus execution environment?

It is not possible to unset a variable in the dbus-daemon's activation
environment, or with `dbus-update-activation-environment`: that's an
API limitation in the org.freedesktop.DBus interface. I've thought about
adding an UnsetAndSetActivationEnvironment() that could do this.

It *is* possible to unset a variable in the `systemd --user`
activation environment, with `systemctl --user unset-environment` or
the UnsetEnvironment() and UnsetAndSetEnvironment() D-Bus methods on the
systemd manager. If your distribution is using dbus-broker rather than
dbus-daemon, and if Mantas was correct to say that dbus-broker does not
have its own separate activation environment, then that should be enough
to affect all D-Bus session services. It will also affect all other
systemd user services.

    smcv