<div dir="auto"><div>The traditional dbus-daemon keeps a separate environment for services it spawns directly (i.e. those that don't specify SystemdService= in their D-Bus .service files), though that it doesn't apply to services it runs via systemd so you need to keep both in sync.<div dir="auto"><br></div><div dir="auto">On the other hand, dbus-broker runs everything via systemd (using transient service units if necessary), and as far as I know it no longer keeps track of a separate activation environment and all changes are just directly forwarded to systemd's environment instead.</div><div dir="auto"><br></div><div dir="auto">It depends on which implementation your distribution uses.</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 8, 2024, 17:58 Vladimir Kudrya <<a href="mailto:vladimir-csp@yandex.ru">vladimir-csp@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello.<br>
<br>
In context of a modern systemd-managed user session, is there a separate <br>
dbus activation environment, or is it merged with systemd? If one <br>
intends to manage environment variables, is systemctl (or <br>
org.freedesktop.systemd1.Manager Environment) enough?<br>
<br>
A variable added by dbus-update-activation-environment (even without <br>
--systemd option) shows up in systemd activation environment. I couldn't <br>
find a pure dbus service to check if reverse is true.<br>
<br>
<br>
<br>
</blockquote></div></div></div>