When I upgrade to dbus-broker should I expect anything to break?
Archdevs, Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices) What has been the experience of the devs in making the change? -- David C. Rankin, J.D.,P.E.
No, you shouldn't even realise you switched, unless you use apparmor. You will get the option between dbus scripts and broker scripts, broker is default. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
On 1/9/24 21:23, Polarian wrote:
No, you shouldn't even realise you switched, unless you use apparmor.
You will get the option between dbus scripts and broker scripts, broker is default.
Thank you Sir, Here goes nothing.... -- David C. Rankin, J.D.,P.E.
Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices) So far one person on the forum claimed dbus-broker has broken their system,⁽¹⁾ but with logs indicating they don’t use dbus-broker, and two people associated issues with updating to dbus-broker,⁽²⁾⁽³⁾ but with no evidence of such connection. No single report in #archlinux since the begining of 2023 (twenty twenty three). No issues observed here either, 12 hours after the update.
This should give you some indication of the current situation. Of course we may still see some issues in the upcoming days, as it’s always expected for deploying such a crucial component, but certainly there is no reason to consider breakage an expected outcome of the update. Modulo the aforementioned AppArmor support. You may wish to have the most recent Live ISO at hand, just in case. As well as restarting the dbus service, after the update is complete, to learn about the issues possibly early and not 7 updates later. Restarting the dbus service is best done from system console: in case it would bring down the entire graphical session. ____ ⁽¹⁾ https://bbs.archlinux.org/viewtopic.php?id=291717 ⁽²⁾ https://bbs.archlinux.org/viewtopic.php?id=291757 ⁽³⁾ https://bbs.archlinux.org/viewtopic.php?id=291729
Hello,
So far one person on the forum claimed dbus-broker has broken their system,⁽¹⁾ but with logs indicating they don’t use dbus-broker, and two people associated issues with updating to dbus-broker,⁽²⁾⁽³⁾ but with no evidence of such connection. No single report in #archlinux since the begining of 2023 (twenty twenty three). No issues observed here either, 12 hours after the update.
I updated my server to dbus-broker, its seemless and on reboot there is no difference. In my case I did have one breakage when I accidentally stopped dbus which killed systemd and the rest was history, however I had another user test this and systemd just restarted dbus and his system was fine, so I guess this is a case of "your millage may vary". My laptop was manually migrated before the changes, I wanted to try out dbus-broker when I saw it suggested in the RFC MR, and that went fine. After the change, the automatic process from pacman on my server (and containers) worked just fine and dbus is being started like expected on boot. There has been other users, such as a staff member [1] which has been using it without issues, so there is not much to fear.
You may wish to have the most recent Live ISO at hand, just in case. As well as restarting the dbus service, after the update is complete, to learn about the issues possibly early and not 7 updates later. Restarting the dbus service is best done from system console: in case it would bring down the entire graphical session.
In all honesty you should always have a installation media handy, the meme of Arch Users carrying around a installation media is not just a meme, its reality. I have lost count the number of times a kernel update has broken my system and I need to rollback the kernel, or device decided to wipe the EFI entries for the giggles (seems to be common with gaming motherboards). Overall, there is little to fear here, and if an idiot like me can do it, I am sure anyone can :P Hope this gives some more confidence in updating. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25#note_148480
On Wed, Jan 10, 2024 at 10:02:44AM +0100, mpan wrote:
No issues observed here either, 12 hours after the update.
I haven't had any issues, either. The only thing I wonder about is that dbus-broker-units replaced /usr/lib/systemd{system,user}/dbus.service with the corresponding dbus-broker.service, why was /usr/lib/systemd{system,user}/dbus.socket left as being owned by dbus? Merell -- "Imitation is the sincerest form of television." -- The New Mighty Mouse
On Tue, 9 Jan 2024 21:07:35 -0600 "David C. Rankin" <drankinatty@gmail.com> wrote:
Archdevs,
Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices)
What has been the experience of the devs in making the change?
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
The only thing I wonder about is that dbus-broker-units replaced
/usr/lib/systemd{system,user}/dbus.service with the corresponding dbus-broker.service, why was /usr/lib/systemd{system,user}/dbus.socket left as being owned by dbus?
it's the same unit file for both services, and the dbus package is more like dbus-lib now (ships the daemon too, but nothing to start it). maybe in the future there would be dbus-common and/or dbus-lib -- damjan
Hello,
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
How did you do this? All it does is replace dbus, they are both API compatible? Define "trashed system"? Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
On Wed, 10 Jan 2024 03:23:42 +0000, Polarian <polarian@polarian.dev> wrote:
No, you shouldn't even realise you switched, unless you use apparmor.
As a matter of fact even AppArmor doesn't make a difference as dbus mediation is not enabled in Arch. Ubuntu uses a patched kernel and a patched dbus-daemon to achieve this. Hence, using dbus-daemon or dbus-broker doesn't make a difference on Arch if it comes to AppArmor.
On Wed, 10 Jan 2024 15:51:37 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
How did you do this? All it does is replace dbus, they are both API compatible?
Define "trashed system"?
Take care,
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke . Pete
On Wed, 10 Jan 2024 15:58:38 +0000 pete <petegn@mail.com> wrote:
On Wed, 10 Jan 2024 15:51:37 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
How did you do this? All it does is replace dbus, they are both API compatible?
Define "trashed system"?
Take care,
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke .
Pete
Your system has serious problems. The python issue was never pacman or Arch problem, something else is going on. This is probably another symptom of the same issue.
Op wo 10 jan. 2024 19:26 schreef pete <petegn@mail.com>:
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke .
Sounds like a good time to run some storage (smartctl) and memory (memtest86?) tests on that system. Losing data once is unfortunate, twice is really suspect. Mvg, Guus
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
Define "trashed system"?
Take care,
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke .
I've been using dbus-broker since … checks logs … 2019-10-18 (version 21 at that time) and there haven't been any issues. I'm not sure it's a problem with the packages. -- damjan
Hello, Like others have said, you really need to backup important files and reinstall your system. -- Cheers, Aᴀʀᴏɴ
On Wed, 10 Jan 2024 11:13:36 -0600 Doug Newgard <dnewgard@outlook.com> wrote:
On Wed, 10 Jan 2024 15:58:38 +0000 pete <petegn@mail.com> wrote:
On Wed, 10 Jan 2024 15:51:37 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
How did you do this? All it does is replace dbus, they are both API compatible?
Define "trashed system"?
Take care,
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke .
Pete
Your system has serious problems. The python issue was never pacman or Arch problem, something else is going on. This is probably another symptom of the same issue.
Well just run a complete check on the drives and memory no issues , i bit the bulletand have done a complete reinstall on slight issue now cant get the darn networking up great off the live dvd but soon as i reboot into main system no networking no connection led on the card or router trhat is for tomorrow Cheers folks PS if anyone has any ideas why this network will not come up it would help Many thanks folks Pete
On Thu, 11 Jan 2024 00:02:00 +0000 pete <petegn@mail.com> wrote:
On Wed, 10 Jan 2024 11:13:36 -0600 Doug Newgard <dnewgard@outlook.com> wrote:
On Wed, 10 Jan 2024 15:58:38 +0000 pete <petegn@mail.com> wrote:
On Wed, 10 Jan 2024 15:51:37 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
How did you do this? All it does is replace dbus, they are both API compatible?
Define "trashed system"?
Take care,
complete list 2 screens full of dbus failures that were NOT there before lastnights "pacman -Syu" now it is trash it was bad enough when a previous update caused me piles of python fails but now this it is getting beyonde a joke .
Pete
Your system has serious problems. The python issue was never pacman or Arch problem, something else is going on. This is probably another symptom of the same issue.
Well just run a complete check on the drives and memory no issues , i bit the bulletand have done a complete reinstall on slight issue now cant get the darn networking up great off the live dvd but soon as i reboot into main system no networking no connection led on the card or router trhat is for tomorrow
Cheers folks
PS if anyone has any ideas why this network will not come up it would help
Many thanks folks
Pete
Replying to my own mail Working at alst had to re install networkmanager dhcpcd for the record the Drives are all ok memory tested out ok . see what happens if it starts acting up again Cheers pete
On 1/10/24 09:28, pete wrote:
On Tue, 9 Jan 2024 21:07:35 -0600 "David C. Rankin" <drankinatty@gmail.com> wrote:
Archdevs,
Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices)
What has been the experience of the devs in making the change?
Be Carefull i now have a totally Trashed system thanks to dbus-broker and i am not happy need to remove it and get back to dbus but it has it locked wn tight
Sorry to hear that, Thankfully, my upgrade went without issue (or I'd be yelling a polarian :) Hopefully those smarter than I on dbus-broker can get you going again. -- David C. Rankin, J.D.,P.E.
Hi, See their reply to Doug. They solved it after reinstalling networkmanager and dhcpcd. -- Cheers, Aᴀʀᴏɴ
On Sat, 13 Jan 2024 11:48:12 -0500 Aaron Liu <aaronliu0130@gmail.com> wrote:
Hi,
See their reply to Doug. They solved it after reinstalling networkmanager and dhcpcd.
I actually had to do a complete reinstall . Pete
Hi folks, I notice that thunderbird does not show notification as system notification. And also I see this error: plasma_waitforname[68941]: org.kde.knotifications: WaitForName: Service was not registered within timeout. Best regards, Severus -- Trên con đường lấy lửa thử vàng anh phát hiện con tim mình chỉ là đá.
I actually had to do a complete reinstall .
Have you actually checked the logs to see what exactly was failing before resorting to that? Someone in the Telegram group had a broken filesystem with a 0 byte kwallet xml file which was breaking the new dbus, it's apparently more strict than the old one. Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: Looking up NSS group entry for 'netdev'... Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: NSS returned no entry for 'netdev' Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: Invalid group-name in /usr/share/dbus-1/system.d/ead-dbus.conf +20: group="netdev" Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: Invalid group-name in /usr/share/dbus-1/system.d/iwd-dbus.conf +22: group="netdev" Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: Invalid XML in /usr/share/dbus-1/system.d/org.kde.kcontrol.kcmkwallet5.conf +1: no element found Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: ERROR run @ ../dbus-broker-35/src/launch/main.c +152: Return code 1 Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: main @ ../dbus-broker-35/src/launch/main.c +178 Jan 11 08:56:50 desktop-a dbus-broker-launch[820]: Exiting due to fatal error: -131 .rw-r--r-- 0 root root 7 Dec 2023 /usr/share/dbus-1/system.d/org.kde.kcontrol.kcmkwallet5.conf Martin On Tue, Jan 16, 2024 at 11:46 AM Severus <huynhok.uit@vnoss.org> wrote:
Hi folks,
I notice that thunderbird does not show notification as system notification.
And also I see this error: plasma_waitforname[68941]: org.kde.knotifications: WaitForName: Service was not registered within timeout.
Best regards, Severus
-- Trên con đường lấy lửa thử vàng anh phát hiện con tim mình chỉ là đá.
Hi, I can't blame dbus-broker alone for the already solved problem [1], but at least it interacts with something and by migrating back to dbus- daemon-units it is obviously solved. Has nobody else had similar experiences? If the problem hadn't happened to occur close to the time dbus-broker was first installed, I would probably still be looking for the cause. Kind regards, Ralf [1] https://bbs.archlinux.org/viewtopic.php?id=292408
participants (13)
-
Aaron Liu
-
adventurer
-
Damjan Georgievski
-
David C. Rankin
-
Doug Newgard
-
Guus Snijders
-
Martin Rys
-
Merell L. Matlock, Jr.
-
mpan
-
pete
-
Polarian
-
Ralf Mardorf
-
Severus