Bug 1499739 - Slow response of the Xfce desktop if plasma-workspace package is installed on some systems
Summary: Slow response of the Xfce desktop if plasma-workspace package is installed on...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xfce4-notifyd
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mukundan Ragavan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-09 10:08 UTC by Jaroslav Škarvada
Modified: 2018-05-29 11:37 UTC (History)
5 users (show)

Fixed In Version: xfce4-notifyd-0.4.0-2.fc26
Clone Of:
: 1499743 (view as bug list)
Environment:
Last Closed: 2018-05-29 11:37:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jaroslav Škarvada 2017-10-09 10:08:28 UTC
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

Comment 1 Jaroslav Škarvada 2017-10-09 10:16:27 UTC
Created plasma workspace bug 1499743.

Comment 2 Rex Dieter 2017-10-09 11:45:42 UTC
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)

Comment 3 Mukundan Ragavan 2017-10-09 16:27:49 UTC
Let me see what options are there ... I will probably file an upstream bug report for the same.

Comment 4 Mukundan Ragavan 2017-10-21 15:14:59 UTC
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).

Comment 5 Jaroslav Škarvada 2017-10-23 11:00:19 UTC
(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.

Comment 6 Jaroslav Škarvada 2017-10-30 20:42:06 UTC
(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.

Comment 7 Fedora Update System 2017-10-30 22:59:57 UTC
xfce4-notifyd-0.4.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c74e5b699

Comment 8 Jaroslav Škarvada 2017-10-31 16:03:48 UTC
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.

Comment 9 Mukundan Ragavan 2017-11-01 01:31:16 UTC
That's unfortunate. I will open this upstream and see what they say.

bodhi will probably close this bug. I will re-open this.

Comment 10 Fedora Update System 2017-11-01 17:22:01 UTC
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

Comment 11 Fedora Update System 2017-11-15 20:13:34 UTC
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.

Comment 12 Konstantin Svist 2017-11-25 18:52:22 UTC
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

Comment 13 Fedora End Of Life 2018-05-03 07:51:38 UTC
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.

Comment 14 Fedora End Of Life 2018-05-29 11:37:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.