Re: [systemd-devel] Activation environment(s)?
At least signals seem to be sent only only once. A process in a login shell can wait for TERM (and two HUPs if on console), wait a bit after this, then safely fork cleanup tasks and exit before KILL comes. On 15/01/2024 13.08, Lennart Poettering wrote: When the goal is to shut down a service/session, then intend to give guarantees that the shut down time is bounded: we first send SIGTERM, and start a timeout. If by that timeout there are still processes left we SIGKILL to put an end to things. If we'd somehow distinguish new/old processes then we couldn't put the boundary on the shutdown process... So no, this does not exist. You can fork if you want, but it won't add time to the time-out. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Activation environment(s)?
On Fr, 12.01.24 18:16, Vladimir Kudrya (vladimir-...@yandex.ru) wrote: > 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? When the goal is to shut down a service/session, then intend to give guarantees that the shut down time is bounded: we first send SIGTERM, and start a timeout. If by that timeout there are still processes left we SIGKILL to put an end to things. If we'd somehow distinguish new/old processes then we couldn't put the boundary on the shutdown process... So no, this does not exist. You can fork if you want, but it won't add time to the time-out. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Activation environment(s)?
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?
Re: Activation environment(s)?
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
Re: Activation environment(s)?
So I'm seeing an artifact of dbus-broker. Is it possible to unset a variable from native dbus execution environment? On 08/01/2024 19.21, Mantas Mikulėnas wrote: 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. 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. It depends on which implementation your distribution uses.
Re: Activation environment(s)?
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. 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. It depends on which implementation your distribution uses. On Mon, Jan 8, 2024, 17:58 Vladimir Kudrya wrote: > Hello. > > In context of a modern systemd-managed user session, is there a separate > dbus activation environment, or is it merged with systemd? If one > intends to manage environment variables, is systemctl (or > org.freedesktop.systemd1.Manager Environment) enough? > > A variable added by dbus-update-activation-environment (even without > --systemd option) shows up in systemd activation environment. I couldn't > find a pure dbus service to check if reverse is true. > > > >
Activation environment(s)?
Hello. In context of a modern systemd-managed user session, is there a separate dbus activation environment, or is it merged with systemd? If one intends to manage environment variables, is systemctl (or org.freedesktop.systemd1.Manager Environment) enough? A variable added by dbus-update-activation-environment (even without --systemd option) shows up in systemd activation environment. I couldn't find a pure dbus service to check if reverse is true.
