Dbus-broker warnings

Support System Updates
,
1

This is an Arch Linux issue but I’m not running Arch and we all know the rules about reporting issues there. It affects Manjaro too of course.

The recent switch to dbus-broker introduced some new warnings. After digging further I found that none of them are cause for immediate concern but they do indicate that Arch and Manjaro use dbus activation in a way that depends on legacy support. In particular

Service file '/usr/share//dbus-1/services/org.kde.dolphin.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'.
Service file '/usr/share//dbus-1/services/org.kde.plasma.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'.

These session service files are named like that to allow multiple DEs to be installed (otherwise they’d all be fighting over e.g. org.freedesktop.FileManager1.service). But dbus-broker does not support that use-case (and never will) and there is no way to disable these warnings. It only allows this naming at all for legacy support.

After Fedora 30 switched to dbus-broker they removed dbus activation of DE-specific org.freedesktop.* session services in Fedora 31. Arch will need do the same IMHO (or continue shipping a distro that outputs warnings indicating use of a dbus legacy support feature).

As for the other warnings;

Activation request for 'org.freedesktop.home1' failed: The systemd unit 'dbus-org.freedesktop.home1.service' could not be found.

Because systemd-homed service is disabled/masked. Can be silenced by commenting out 4 lines referring to pam_systemd_home.so in /etc/pam.d/system-auth. See [solved] pam fails to find unit dbus-org.freedesktop.home1.service / Newbie Corner / Arch Linux Forums

Activation request for 'org.freedesktop.resolve1' failed: The systemd unit 'dbus-org.freedesktop.resolve1.service' could not be found.

Because systemd-resolved service is disabled/masked. Can be silenced by adding systemd-resolved=false option to NetworkManager configuration;

echo -e '[main]\nsystemd-resolved=false' | sudo tee /etc/NetworkManager/conf.d/no-systemd-resolved.conf

Service file '/usr/share//dbus-1/services/org.kde.kscreen.service' is not named after the D-Bus name 'org.kde.KScreen'.

Seems to be an upstream issue, as far as I can see there’s no good reason for it not to be capitalised correctly.

3 Likes
2

During the update myself (and I assume you and everyone on stable) get the choice:

resolving dependencies...
:: There are 2 providers available for dbus-units:
:: Repository core
   1) dbus-broker-units  2) dbus-daemon-units

Enter a number (default=1):

The default is for the current Arch testing repo?

(dbus-daemon-units vs dbus-broker-units / [testing] Repo Forum / Arch Linux Forums)

Edit: I re-read the announcement. default=1 is what we’re supposed to do.

3

To avoid potential issues you can choose option 2.

1 Like
4

I just ignore these warnings unlike error messages.

I got the “error” message for example “duplicate files exist”

That is fine for me to fix the issue and remove these duplicate files.

I switched to dbus-daemon-units, but it does not check duplicate files and some serious issues.

5

This is another example of incorrect use of dbus auto activation. If there are two service files providing the same service (in this case KDE and Dunst both provide the org.freedesktop.Notifications service) then whichever one gets loaded first wins. And since the specification doesn’t define load order you can’t know which one that is. This is pointed out at Dunst - ArchWiki

No service with multiple providers should be using dbus auto activation. Those services should be explicitly started when the DE starts, as Fedora does.

Functionally dbus-broker and dbus-daemon do exactly the same thing, the only difference is that dbus-broker outputs warnings when it finds multiple providers or incorrectly named service files. Which is good and hopefully will result in this all being cleaned up in the future as it was in Fedora.

2 Likes
6

Right. Using different service file names for conflicting D-Bus services only prevents the file conflict when installing both packages, but not the runtime conflict when the service is actually to be activated. D-Bus never got that right, and after almost 15 years (!) of nobody caring, I do not expect that to change any time soon, neither in the legacy dbus-daemon nor in dbus-broker. D-Bus activation is not a suitable solution for desktop-environment-specific implementations of a standardized D-Bus API.

1 Like
7

I found the offending commit https:/ /invent.kde.org/plasma/kscreen/-/commit/f99eec01a366726890b6b92ff3ff209af27df6e6#72fb4914edba55cfa5a138bf0fb0d75a30520d71_59_59

seems to be fixed now in master. :+1: