0

The visible part of the bug is that I get multiple notifications when changing the volume:

Multiple volume notifications

The symptoms look identical to that of a question on AskUbuntu but, since it might be a different cause, and I am not actually using Ubuntu, I am opening a new question.

After some tinkering around, I noticed something strange. When calling the Notify method of the xorg.freedesktop.Notifications D-Bus service, I can display a notification, but I get an error in return:

Calling the Notify methods works but return an error

Since I am using d-feet to browse the D-Bus services and inspecting the method signature, I am pretty I am using the right argument types (I get more specific errors otherwise). I get the same error when using notify-send:

~% notify-send a                                                              
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Notify" with signature "susssasa{sv}i" on interface "org.freedesktop.Notifications" doesn't exist

At least one other person has encountered the same issue around the same time: https://www.linuxquestions.org/questions/slackware-14/pygobject-desktop-notifications-stopped-working-4175710943/

When comparing with a Xubuntu 20.04 without the bug, I see that it is supposed to return the id of the notification, which can then be used as the replacedid parameter to update the notification. That would explain why xfce4-pulseaudio-plugin cannot update the first notification and instead open new ones.

I am using Debian testing (bookworm) with the latest updates, with xfce4=4.16, xfce4-pulseaudio-plugin=0.4.3-1, xfce4-notifyd=0.6.3-1 and dbus=1.14.0-1. Also note that xorg.freedesktop.Notifications is actually provided by /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service:

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd
SystemdService=xfce4-notifyd.service

I guess it might plausibly be a bug of xfce4-pulseaudio-plugin, dbus, xfce4-notifyd, or, more likely, my configuration. What can I do to get to the bottom of it?

1 Answer 1

1

I did not think it would be enough to find a solution, but just looking at D-Bus logs got me on the right track.

So, I ran the following command while opening a notification from d-feet.

dbus-monitor >log

In the log, I was able to find the corresponding exchange:

method call time=1656781561.510107 sender=:1.75 -> destination=:1.48 serial=325 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
   string "Test"
   uint32 0
   string "computer"
   string "Title"
   string "Body"
   array [
   ]
   array [
   ]
   int32 1
error time=1656781561.510300 sender=:1.61 -> destination=:1.75 error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=325
   string "Method "Notify" with signature "susssasa{sv}i" on interface "org.freedesktop.Notifications" doesn't exist
"

It contains the same information I had, except that it also includes ids for the communicating services . You can see that the method call was sent from :1.75 (d-tree itself) to :1.48 (the D-Bus service for xfce4-notifyd as per d-tree, as show in the screenshot below).

The D-Bus service provided by xfce4-notifyd in d-tree

However, the error comes from :1.61. Looking in d-tree, I notice the eavesdrop=true, which hints to me that another service did something to the method call.

The other unexpected service in d-tree

Looking around, I end up on a post about deprecating eavesdropping in session.conf of D-bus. Scanning my system, I locate /usr/share/dbus-1/session.conf, apply the following patch and restart my session. Now, everything is fine!

-    <allow send_destination="*" eavesdrop="true"/>
+    <allow send_destination="*" eavesdrop="false"/>
     <!-- Allow everything to be received -->
-    <allow eavesdrop="true"/>
+    <allow eavesdrop="false"/>

My understanding is that the original service did its work properly, but another service tried to handle it, failed because it did not have the proper Notify method (or the wrong signature). I have no idea where this eavesdropping comes from, and a proper fix would imply identifying it. However, the workaround seems to solve my initial issue.


Edit: I have found the culprit by running grep -r freedesktop.Notifications ~/.local. It turns out I had not updated the Discover overlay, which is not managed by apt. After running pip install --upgrade discover-overlay, and reverting my changes to /usr/share/dbus-1/session.conf, everything is back to normal!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .