[systemd-devel] Activation environment(s)?

[Vladimir Kudrya]

On 08/01/2024 22.26, Simon McVittie wrote:
> 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.

Thank you. I now recommend dbus-broker in my session manager's readme 
(https://github.com/Vladimir-csp/uwsm), and management of dbus 
activation environmentis now conditional on dbus unit true name not 
being dbus-broker.service.

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240112/1c973c41/attachment.htm>