Bugzilla – Bug 1188532
Make dbus and dbus-broker equal citizens on TW
Last modified: 2024-06-16 11:13:46 UTC
1. are there any issues left that need to be solved before we could e.g. change the default from dbus to dbus-broker? is this even wanted? 2. dbus-broker is meant to be a drop in replacement for dbus. our dbus system service blocks any restarting or stopping. dbus-broker on the other hand allows it. and unlike in the past ... systemd seems to handle restart of dbus in a graceful way now. can we allow restarting of dbus as well now?
There are two problems left, one is the systemd.rpm with a wrong requires: "dbus-1 >= 1.4.0 is needed by (installed) systemd-248.3-2.1.x86_64" The other is the dbus-1 packaging, you need to split out the dbus daemon. But if you override the presets and ignore the useless installed dbus-1 daemon, you can switch already today to dbus-broker, works without problems. Fedora switched years ago to dbus-broker without any problems.
Ok, looks like we only need to adjust dbus-1 and move dbus-daemon dbus-launch to a separate package (maybe dbus-1-daemon?) So our "dbus-1" package should contain what Fedora has in dbus-tools and dbus-common, and it should require "dbus-1-daemon or dbus-broker". Second step would be to change the patterns and presets.
Yeah as the dbus maintainer for SLE-16 i'd much prefer us to move to dbus-broker like Thorsten said I think fedora has it at the point where that is reasonable. I just haven't had the time to make it work yet, its high on my list but some things for the SP4 beta just got added so they are slightly higher. Ideally i'd like to spend some time running it on my machines before I send it to factory.
> 2. dbus-broker is meant to be a drop in replacement for dbus. our dbus > system service blocks any restarting or stopping. dbus-broker on the other > hand allows it. and unlike in the past ... systemd seems to handle restart > of dbus in a graceful way now. can we allow restarting of dbus as well now? The reason we don't allow restarting dbus at the moment is more because a significant number of programs didn't handle dbus going away and coming back well, they tend to just presume that if they connect to dbus once it will be there for life. I'm unsure if dbus-broker makes this better by restoring state but either way removing the current description will probably be more dependent on programs being able to handle dbus-broker restarting then dbus or dbus-broker itself. Otherwise we start getting L3 bug reports saying "I did an update and service X died"
As I said ... one of those services was systemd in the past. and currently dbus-broker allows restarting. so we need to settle on one side and fix the fallout. (in doubt blocking restart of dbus-broker too)
Yeah my next step is moving to dbus-broker with restart disabled until someone has time to check that restarting doesn't break any of the major services we ship with SLE or any desktop environments. But yeah once we have dbus-broker working well then my plan is to drop dbus-daemon having both doesn't make sense.
tbh ... instead of disabling restart in dbus-broker. we fix all the services which rely on dbus to have proper dependencies on dbus in their service files so they get properly restarted. right now a dbus-broker restart on a desktop machine leads to broken login/gdm. if we had proper dependencies everywhere the whole stack would be pulled down and then restarted with dbus.
(In reply to Marcus Rückert from comment #7) > tbh ... instead of disabling restart in dbus-broker. we fix all the services > which rely on dbus to have proper dependencies on dbus in their service > files so they get properly restarted. right now a dbus-broker restart on a > desktop machine leads to broken login/gdm. > > if we had proper dependencies everywhere the whole stack would be pulled > down and then restarted with dbus. This starts to get a whole lot messier when you consider parts of the stack are desktops and desktop environments. I know for example enlightenment is restartable but not currently from a systemd dependency. Maybe we could introduce a dbus-block-restart package and require it for anything we suspect can't handle updates well. At the same time given dbus related security updates don't happen that often compared to other packages maybe the solution of least effort is userspace live patching.
Well not sure how other display-manager handles it. but GDM goes down completely. which takes down my session. So yes after logging back in my session is there again ;)
well as apparently Arch has just moved to dbus-broker as well, and so has many others ...I was wondering what is the status for SUSE? https://www.phoronix.com/news/Arch-Linux-Dbus-Broker
zypper in dbus-broker systemctl enable dbus-broker reboot done.
(In reply to Marcus Rückert from comment #11) > zypper in dbus-broker > systemctl enable dbus-broker > > reboot > > done. sure, I was thinking more about making it default like other (major) distros...maybe should make new bug report?
>systemctl enable dbus-broker surely also `systemctl disable dbus`. Can't be good to have two daemons running trying to own the dbus socket, can it..
not really needed iirc.(In reply to Alexander Ahjolinna from comment #12) > sure, I was thinking more about making it default like other (major) > distros...maybe should make new bug report? This is also work in progress. My point was more you can test and use it already without us switching the default. (In reply to Jan Engelhardt from comment #13) > >systemctl enable dbus-broker > > surely also `systemctl disable dbus`. Can't be good to have two daemons > running trying to own the dbus socket, can it.. iirc you do not have to disable dbus manually.
(In reply to Alexander Ahjolinna from comment #12) > (In reply to Marcus Rückert from comment #11) > > zypper in dbus-broker > > systemctl enable dbus-broker > > > > reboot > > > > done. > > sure, I was thinking more about making it default like other (major) > distros...maybe should make new bug report? No need, the submit request for this change is already sitting in a staging, its just waiting for reviews. We'd also like to have it as the default in ALP.
(In reply to Simon Lees from comment #15) > (In reply to Alexander Ahjolinna from comment #12) > > (In reply to Marcus Rückert from comment #11) > > > zypper in dbus-broker > > > systemctl enable dbus-broker > > > > > > reboot > > > > > > done. > > > > sure, I was thinking more about making it default like other (major) > > distros...maybe should make new bug report? > > No need, the submit request for this change is already sitting in a staging, > its just waiting for reviews. We'd also like to have it as the default in > ALP. well okay good to know. I was just wondering as I saw the arch update and there hasnt been no action on this bug report in a long time.