Description of problem: The plasma-workspace package installs D-Bus Notifications service, which can be started by dbus-daemon if other DE component requests notification instead of the other DE notification service. It seems it happens because the dbus-daemon scans the /usr/share/dbus-1/services directory by using readdir which calls getdents syscall. No postprocessing seems to be done, so the entries are added to the hash table in order returned by the readdir which can be arbitrary, from the manual page: "The order in which filenames are read by successive calls to readdir() depends on the filesystem implementation; it us unlikely that the names will be sorted in any fashion." The following analysis is for xfce, but I think similar problem can happen with other DEs as well. Because org.xfce.xfce4-notifyd.Notifications.service uses the same bus name as the org.kde.plasma.Notifications.service (i.e. Name=org.freedesktop.Notifications), on systems where readdir returns org.kde.plasma.Notifications.service before the org.xfce.xfce4-notifyd.Notifications.service the Xfce4 notifications requests try to use the KDE Plasma notification service, which of course fails with timeout. The problem manifests as a slow response of the Xfce desktop. E.g. for the xfce4-power-manager when the user change brightness of the display or connects/disconnects AC power the event is processed after dozens of seconds. Similarly for other functionality using the Notification service. Version-Release number of selected component (if applicable): plasma-workspace-5.10.5-3.fc26.x86_64 How reproducible: Always, but only on systems where readdir returns org.kde.plasma.Notifications.service before org.xfce.xfce4-notifyd.Notifications.service Steps to Reproduce: 1. Install plasma-workspace: 2. Install Xfce4 desktop 3. Run Xfce4 desktop 4. Run: 'notify-send test' Actual results: Timeout Expected results: No timeout, notification is correctly displayed Additional info: This problem also appeared in the f25 after some update. I am not sure how to correctly resolve this due to D-Bus configuration limitations and Freedesktop Notification service specification. Maybe alternatives system (man alternatives) can be used for the Notification service configuration? Or some startup script? Maybe the notification daemons could be started by the xinit scripts according to DE selected. But it will require cooperation between multiple DEs maintainers. Or maybe Conflicts keyword could be added to the both spec files. According to the [1] it will probably require ticket to the Fedora Packaging Committee. I opened similar bug for xfce as bug 1499739. There maybe the same problem with other desktops environments using their own Notification service, i.e. the problem may happen if the user just install multiple desktop environments. Strace of the dbus-deamon serving the session bus on the system where it doesn't work (note that org.kde.plasma.Notifications.service content is read before the org.xfce.xfce4-notifyd.Notifications.service content)": [pid 1943] open("/usr/share/dbus-1/services", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 74 [pid 1943] fstat(74, {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 [pid 1943] getdents(74, /* 136 entries */, 32768) = 7912 ... [pid 1943] stat("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", {st_mode=S_IFREG|0644, st_size=114, ...}) = 0 [pid 1943] open("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", O_RDONLY) = 81 [pid 1943] fstat(81, {st_mode=S_IFREG|0644, st_size=114, ...}) = 0 [pid 1943] read(81, "[D-BUS Service]\nName=org.freedes"..., 114) = 114 [pid 1943] close(81) = 0 [pid 1943] stat("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", {st_mode=S_IFREG|0644, st_size=114, ...}) = 0 ... [pid 1943] stat("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", {st_mode=S_IFREG|0644, st_size=132, ...}) = 0 [pid 1943] open("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", O_RDONLY) = 81 [pid 1943] fstat(81, {st_mode=S_IFREG|0644, st_size=132, ...}) = 0 [pid 1943] read(81, "[D-BUS Service]\nName=org.freedes"..., 132) = 132 [pid 1943] close(81) = 0 [pid 1943] stat("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", {st_mode=S_IFREG|0644, st_size=132, ...}) = 0 Strace of the dbus-deamon serving the session bus on the system where it works OK (note that org.xfce.xfce4-notifyd.Notifications.service content is read before the org.kde.plasma.Notifications.service content)": 1262 open("/usr/share/dbus-1/services", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 42 1262 fstat(42, {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 1262 getdents(42, /* 142 entries */, 32768) = 8312 ... 1262 stat("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", {st_mode=S_IFREG|0644, st_size=132, ...}) 1262 open("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", O_RDONLY) = 68 1262 fstat(68, {st_mode=S_IFREG|0644, st_size=132, ...}) = 0 1262 read(68, "[D-BUS Service]\nName=org.freedes"..., 132) = 132 1262 close(68) = 0 1262 stat("/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service", {st_mode=S_IFREG|0644, st_size=132, ...}) ... 1262 stat("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", {st_mode=S_IFREG|0644, st_size=115, ...}) = 0 1262 open("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", O_RDONLY) = 68 1262 fstat(68, {st_mode=S_IFREG|0644, st_size=115, ...}) = 0 1262 read(68, "[D-BUS Service]\nName=org.freedes"..., 115) = 115 1262 close(68) = 0 1262 stat("/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", {st_mode=S_IFREG|0644, st_size=115, ...}) = 0 [1] https://fedoraproject.org/wiki/Packaging:Conflicts
This is likely a variant of the old dbus bug #484945 "D-Bus activation needs a way to prefer one service over the other depending on the running desktop environment" The consensus until we have something better is that each DE is responsible for autostarting it's own notification service (and not rely on dbus activation) *** This bug has been marked as a duplicate of bug 484945 ***