dbus: [WIP] new version and socket activation #18382
Conversation
We now socket activate dbus, which means it will be launched on demand. There is no longer any reason to launch it manually from the various startup scripts and the services.xserver.startDbusSession has thus been deprecated. This is upstream's recommended way to run dbus.
|
@peterhoeg, thanks for your PR! By analyzing the annotation information on this pull request, we identified @ttuegel, @lethalman and @cruegge to be potential reviewers |
|
New version is already in staging |
|
Thanks, but we still need the additional |
|
I can confirm that this PR works properly with KDE in a VM. I'm currently trying with XFCE but that will be another few hours before it's ready... |
|
Let's also test what happens if you restart the dbus while desktop manager is running |
|
I've just tried the following, which works perfectly fine: systemctl --user reload dbusBut, this isn't quite as good: systemctl --user restart dbusWhile the dbus service restarts correctly, everything that was activated using dbus activation is no longer running (kuiserver5, kglobalaccel, kscreen_backend_launcher). The desktop otherwise runs but of course the services provided by those 3 daemons are no longer available. I think there are 2 points here: a) In general the user dbus service shouldn't be restarted, which is why we set b) In the long run, dbus will not spawn services itself, but instead use systemd for spawning (the system level dbus instance does this). I have a few services here running like that (kwalletd5, kdeconnect) and they do survive the dbus restart. |
|
I've just tried with xfce and restarting dbus restarts the session. But without socket activation (and thus not using systemd to keep track of the service), killing dbus kills the xfce session, but as it isn't being auto-spawned, I'm left with just the desktop image and nothing else. So we're actually better off with socket activation. |
|
Any concerns about this? And are we too late for 16.09? |
If this is ready, I can merge it into staging. It's probably too late for 16.09 because it won't even be in master for some time, but I leave the final determination there to @domenkozar. |
|
It depends on the outcome of #16514 If we decide to restart dbus on upgrade, I'd like to have this included since it improves the impact of restart. |
|
@domenkozar - that's unrelated. This PR relates to socket activation of the user dbus instance, whereas #16514 has to do with restarting the system dbus instance. |
|
@peterhoeg I thought user dbus instance is also restarted if dbus is upgraded/restarted. Is that not right? |
|
They should be unrelated. I'll do some digging. |
|
I've just tried in a VM. You can go wild on the system instance - it doesn't touch the user instance when restarted. |
The following changes are included: 1) install user unit files from upstream dbus 2) use absolute paths to config for --system and --session instances 3) make socket activation of user units configurable There has been a number of PRs to address this, so this one does the bare minimum, which is to make the functionality available and configurable but defaults to off. Related PRs: - NixOS#18382 - NixOS#18222
The following changes are included: 1) install user unit files from upstream dbus 2) use absolute paths to config for --system and --session instances 3) make socket activation of user units configurable There has been a number of PRs to address this, so this one does the bare minimum, which is to make the functionality available and configurable but defaults to off. Related PRs: - NixOS#18382 - NixOS#18222
The following changes are included: 1) install user unit files from upstream dbus 2) use absolute paths to config for --system and --session instances 3) make socket activation of user units configurable There has been a number of PRs to address this, so this one does the bare minimum, which is to make the functionality available and configurable but defaults to off. Related PRs: - #18382 - #18222
The following changes are included: 1) install user unit files from upstream dbus 2) use absolute paths to config for --system and --session instances 3) make socket activation of user units configurable There has been a number of PRs to address this, so this one does the bare minimum, which is to make the functionality available and configurable but defaults to off. Related PRs: - #18382 - #18222 (cherry picked from commit f7215c9) Signed-off-by: Domen Kožar <domen@dev.si>
|
what is the state of this pull request? |
|
Most of this has already been merged in a separate PR. I'll clean this up and either close or resubmit. |
|
@peterhoeg Any update on this pull request? |
|
We can close this. |
Motivation for this change
This is WIP - as it requires significant recompilation, my poor laptop is currently adding to global warming. I will be back with an update once I actually manage to run this.
This PR supersedes #18222.
We now socket activate dbus, which means it will be launched on demand.
There is no longer any reason to launch it manually from the various startup scripts and the services.xserver.startDbusSession has thus been deprecated.
This also removes the need for the configurable option in #18222.
This is upstream's recommended way to run dbus.
cc: @ttuegel @lethalman @edolstra
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)