Description of problem: The plasma-workspace package installs D-Bus Notifications service, which can be started by dbus-daemon if Xfce package requests notification instead of the xfce4-notifyd service. It can cause timeouts of dozens seconds and very slow response of the Xfce desktop. 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." 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): xfce4-notifyd-0.3.6-1.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 will also open similar bug against plasma-workspace and will link them together. There maybe the same problem with other desktops environments using their own Notification service, i.e. the problem may happen if the user has installed 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
Created plasma workspace bug 1499743.
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)
Let me see what options are there ... I will probably file an upstream bug report for the same.
Jaroslav, can you test this update and see if it helps this issue? https://bodhi.fedoraproject.org/updates/xfce4-notifyd-0.4.0-2.fc27 If you want a F26 specific build, use this scratch build - https://koji.fedoraproject.org/koji/taskinfo?taskID=22593835 Please be aware this update is also a feature update (has notification logging, new disappear animation and a panel icon that can be enabled if needed).
(In reply to Mukundan Ragavan from comment #4) > Jaroslav, can you test this update and see if it helps this issue? > > https://bodhi.fedoraproject.org/updates/xfce4-notifyd-0.4.0-2.fc27 > > > If you want a F26 specific build, use this scratch build - > > https://koji.fedoraproject.org/koji/taskinfo?taskID=22593835 > > > Please be aware this update is also a feature update (has notification > logging, new disappear animation and a panel icon that can be enabled if > needed). Thanks, I installed the package and I will provide feedback.
(In reply to Jaroslav Škarvada from comment #5) > (In reply to Mukundan Ragavan from comment #4) > > Jaroslav, can you test this update and see if it helps this issue? > > > > https://bodhi.fedoraproject.org/updates/xfce4-notifyd-0.4.0-2.fc27 > > > > > > If you want a F26 specific build, use this scratch build - > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=22593835 > > > > > > Please be aware this update is also a feature update (has notification > > logging, new disappear animation and a panel icon that can be enabled if > > needed). > > Thanks, I installed the package and I will provide feedback. Sorry for delay, it seems to work OK and I am unable to reproduce the problem with this package.
xfce4-notifyd-0.4.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c74e5b699
I was probably too optimistic :) After an upgrade of some packages (which probably caused reorder of the inodes) the problem appears again even with the xfce4-notifyd-0.4.0-2.fc26.x86_64 I think the only robust solution for this problem is to start the notification dbus service by the xfce startup script, not autostart it by the dbus daemon itself, as has been proposed earlier by the plasma-workspace maintainers.
That's unfortunate. I will open this upstream and see what they say. bodhi will probably close this bug. I will re-open this.
xfce4-notifyd-0.4.0-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c74e5b699
xfce4-notifyd-0.4.0-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
I've been hitting the same bug on F26/XFCE for the last several weeks. After reading this and similar/related http://forum.xfce.org/viewtopic.php?id=11382 my temporary workaround is to add /usr/bin/systemctl --user start xfce4-notifyd.service to user autostart. This helps with the biggest problem, which is volume and brightness controls (via keyboard shortcuts/buttons) freeze up while trying to notify user of the status. I use volume and brightness buttons a lot, so I'd say this is a high priority bug for me
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.