<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 08/01/2024 22.26, Simon McVittie
wrote:<br>
</div>
<blockquote type="cite" cite="mid:ZZxMfIyZVzqn8wBe@horizon"><span
style="white-space: pre-wrap">
</span>
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<p>Thank you. I now recommend dbus-broker in my session manager's
readme (<a class="moz-txt-link-freetext" href="https://github.com/Vladimir-csp/uwsm">https://github.com/Vladimir-csp/uwsm</a>), and management of <span
style="white-space: pre-wrap">dbus activation environment</span><span
style="white-space: pre-wrap"> is now conditional on dbus unit true name not being dbus-broker.service.</span></p>
<p><span style="white-space: pre-wrap">BTW, the whole reason I even decided to interact with dbus is rather aggressive session termination by systemd. It seems to send signals not only to existing processes in the session, but even to new ones which were spawned in response to those signals. This makes it impossible to fork a systemctl process to stop related user units.</span></p>
<p><span style="white-space: pre-wrap">I solved this by interacting with dbus without spawning new processes, but, just for info, is there a proper way to fork something that survives for a bit in a session that is being terminated? With simple tools like `trap 'something' TERM HUP` in a shell? Or maybe there is some other more native way to bind a user level unit to a particular session scope?
</span></p>
</body>
</html>