Bug 1471560 - "notify-send" stopped working under fc26
Summary: "notify-send" stopped working under fc26
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: libnotify
Version: 27
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-16 22:55 UTC by Todd
Modified: 2018-11-30 17:32 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 17:32:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1470293 0 unspecified CLOSED Checking sound volume control on Fedora 26 2021-02-22 00:41:40 UTC

Internal Links: 1470293

Description Todd 2017-07-16 22:55:50 UTC
Dear Fedora,

I just upgraded from fc25 to 26 on two machines.  "notify-send" stopped working on both.

Examples to test:

notify-send Test "I'm a test."

notify-send -u normal -i /usr/share/icons/gnome/48x48/status/stock_dialog-warning.png summary "test text"

From /var/log/messages:

Jul 16 15:52:46 KVM-Fedora-x64 dbus-daemon[992]: [session uid=500 pid=992] Activating service name='org.freedesktop.Notifications' requested by ':1.54' (uid=500 pid=2038 comm="notify-send Test I'm a test. " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")


This breaks a bunch of stuff.  Libnotify is used by a lot of my programs.

-T

Comment 1 Todd 2017-07-16 23:43:59 UTC
ooops, sorry.

$ rpm -qa \*libnotify\*
libnotify-0.7.7-2.fc26.x86_64

Comment 2 Todd 2017-07-18 07:29:41 UTC
New info:

I qemu-kbm booted Fedora-Xfce-Live-x86_64-26-1.5.iso.  Send-notify worked perfectly.  This must have something to do with the fc25 to fc26 upgrade.

Others on the Fedora forum have told me their fresh installs also worked.

This must have something to do with the FC25 to FC26 upgrade.

Comment 3 Todd 2017-07-18 19:08:59 UTC
More info:  `dnf reinstall libnotify` made no difference

Comment 4 Todd 2017-07-21 23:50:30 UTC
This bug is wrecking havoc on a lot of stuff.  Is there any data or troubleshooting I can do to help?

Comment 5 Gerry Graesser 2017-07-27 12:01:48 UTC
I also upgraded from Fedora 25 to Fedora 26 without doing a fresh install. Initial install on Fedora 24 was based on Xfce x86_64 Spin and I am (still) running Xorg (not the new wayland).

Here is what I see from journalctl [-e] when I try a simple notify-send:

Jul 26 16:13:00 localhost dbus-daemon[1071]: [session uid=1001 pid=1071] Activating service name='org.freedesktop.Notifications' requested by ':1.194' (uid=1001 pid=4467 comm="notify-send --urgency=normal --icon=phone --expire")
Jul 26 16:14:00 localhost plasma_waitforname[4471]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Jul 26 16:14:00 localhost dbus-daemon[1071]: [session uid=1001 pid=1071] Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1

I am wondering if this issue has anything to do with [still] running Xorg instead of wayland.

Comment 6 Todd 2017-07-27 15:19:04 UTC
My `journalctl -ef` gives (looks identical):

dbus-daemon[1004]: [session uid=500 pid=1004] Activating service name='org.freedesktop.Notifications' requested by ':1.51' (uid=500 pid=1570 comm="notify-send Test I'm a test. " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")

plasma_waitforname[1574]: org.kde.knotifications: WaitForName: Service was not registered within timeout

dbus-daemon[1004]: [session uid=500 pid=1004] Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1

Comment 7 Todd 2017-07-27 18:45:54 UTC
I qemu-kbm booted Fedora-Xfce-Live-x86_64-26-1.5.iso where notify-send works and checked if I was using Xorg or Wayland:

$ echo $XDG_SESSION_TYPE
x11

I am using X11.  So, huh ...

Comment 8 Gerry Graesser 2017-07-28 15:09:55 UTC
In order to try and debug this issue a bit more I booted up the Fedora 26 Xfce Live DVD and did an "rpm -q -a | sort" and compared that to the list of rpms that I had on my updated Fedora 26 system. I found about 40 packages on the Live DVD that I did not have on my updated Fedora 26 system.

So rather than mess up my primary disks I use "rsync -aHxX --numeric-ids --checksum --delete ..." like I always do to backup to ny second drive which I can boot from to do testing there. After a lot of messing around I found that "notify-send" was working on my backup copy and that the "dnf install" and subsequent "dnf erase" of the missing packages made no difference.

So I did another rsync from my primary disks, where "notify-send" was not working, to my backup disk where "notify-send" was working. I expected to find out that "notify-send" was no longer working when I rebooted on my backup disk but that was not the case, it was still working.

So did an rsync from my backup disk back to my primary disk but that did not help - "notify-send" still would not work on my primary disk (root) parition.

So I just finish do a "dd" of my backup root partion to my primary root parition and executed "e2label" to restore the correct label (root) and executed "tune2fs" to restore the correct UUID and then copied the correct version of /etc/fstab for my primary root partition and then when I booted up on my primary (root) partition/disk again. Now "notify-send" IS working on my primary disk partitions.

This leads me to believe that this is some sort of SElinux issue BUT I have SElinux DISABLED on my system.

Comment 9 Peter Fales 2017-07-28 18:49:47 UTC
Just confirming this with another data point.   On an F26 VM upgraded from F25, notify-send does not work.   On a fresh F26 install from scratch, it does not work

Comment 10 Peter Fales 2017-07-28 18:50:55 UTC
Sorry - meant to say that on a fresh  F26 install it *does* work for me, but not on the upgraded system.

Comment 11 Todd 2017-07-30 05:08:35 UTC
Upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=785583

Comment 12 Alfredo Ferrari 2017-08-18 07:12:24 UTC
Same here: on three different computers, all updated from F25 to F26, notify-send and in general all xfce notifications do not work on two of them, while they work on the third one...
It is really a big issue since a lot of things do depend on notifications working (eg nm-applet, power-manager etc, brightness control...) and every one of them get stuck for a long timeout when trying to do something

Comment 13 Alfredo Ferrari 2017-08-18 07:47:21 UTC
... as additional info, I do not know if it is relevant, the two machines where notify does not work have been through Fedora 24->25->26, while the one where it works has been through 25->26 only

Comment 14 Todd 2017-08-18 17:06:23 UTC
(In reply to Alfredo Ferrari from comment #13)
> Fedora 24->25->26, while the
> one where it works has been through 25->26 only

Confirmed here too.  My two machines with 24->25->26 both have the issue, but my 25->26 machine does not.

Additional info.  I noticed the the color of the pop up changed.  Previously the pop up was a white background with black lettering.  Now it is a black background with white lettering.

Comment 15 Alfredo Ferrari 2017-08-18 19:55:12 UTC
I can also confirm the weird system partition->backup->system partition behaviour described above.

I copied (with cp -pduvR --preserve=all etc) the system partition to a backup one, and booted on that one, automagically on the backup partition notify works!!! Despite I didn't change one bit...
I tried to copy back the backup partition in the same way into the "official" one, even after reformatting the "official one", and as described above notify was still failing on the main partition. Then I dd'ed the backup partition on the main one and suddenly everything worked also on the main partition. Done on both machines 24->25->26 and it did work on both. It is really weird. I cannot understand what is changing in this gymnastics... . I definitively believe something strange is left on the system partitions generated during a F24 (or F23, one of the machines actually was a 23->24->25->26) installation.

Comment 16 Todd 2017-08-21 10:48:00 UTC
would a 

    strace notify-send test test

be helpful?

Comment 17 Ned 2017-08-22 11:28:49 UTC
Hi there, 

I also have the problem on a machine with 24->25->26 installed (Mate spin)
with journalctl -b I can see several messages containing 
"Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1"

the [system>control center>appearance>event notifications] control panel doesn't work properly (very often unresponsive) and finishes with an alert box saying 
"Error when displaying notification : Error during call of StartServiceByName for org.freedesktop.Notifications : waiting time exceeded"
(this is a translation from french "Erreur lors de l'affichage d'une notification : Erreur lors de l'appel de StartServiceByName pour org.freedesktop.Notifications : Le délai d'attente est dépassé")

I noticed this because opening my session takes 52 seconds, with 50 spent trying to activate org.freedesktop.Notifications : 

extract of journactl -b :

août 18 10:23:48 NedProBook dbus-daemon[1364]: [session uid=1000 pid=1364] Activating service name='org.freedesktop.Notifications' requested by ':1.24' (uid=1000 pid=1515 comm="notify-send VBoxClient: the VirtualBox kernel serv")
août 18 10:24:38 NedProBook dbus-daemon[1364]: [session uid=1000 pid=1364] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.27' (uid=1000 pid=1353 comm="mate-session ")

I'd be glad to post here any command result that can help

Comment 18 Ned 2017-08-22 11:31:54 UTC
oops, sorry, missing end of sentence : 

I noticed this because opening my session takes 52 seconds to start (measured between the moment I hit enter after typing my password in LightDM and the moment when my mouse cursor changes to the theme I set, followed by my desktop appearing. during this time nothing seems to happen), with 50 spent trying to activate org.freedesktop.Notifications

Comment 19 Todd 2017-08-22 17:27:42 UTC
Just out of curiosity, what is your selinux level:

$ getenforce

Comment 20 Ned 2017-08-23 07:21:23 UTC
$ getenforce
Disabled

...which should not, I never asked it to be disabled. So I check if installed according to what says https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html

# rpm -qa | grep selinux
libselinux-python3-2.6-7.fc26.x86_64
rpm-plugin-selinux-4.13.0.1-5.fc26.x86_64
libselinux-python-2.6-7.fc26.x86_64
libselinux-utils-2.6-7.fc26.x86_64
libselinux-2.6-7.fc26.x86_64
libselinux-2.6-7.fc26.i686
[root@NedProBook ~]# rpm -q policycoreutils
policycoreutils-2.6-6.fc26.x86_64

# dnf info selinux-policy-targeted
returns that the package is available, not installed !

I installed all needed packages (still according to ttps://docs.fedoraproject.org), set SELinux and reboot (to be continued)

Comment 21 Ned 2017-08-23 07:43:48 UTC
(continuing) : SELinux did its labelling job at reboot, rebooted afterwards, and nothing changed. Still 52" to open my session, still org.freedesktp.notification errors in boot log.
It's in permissive mode, I checked it's log, nothing about org.freedesktop.notifications

Comment 22 Alfredo Ferrari 2017-08-23 07:45:10 UTC
... in my case I had SELinux installed and working and the issue was there with no AVC (hence I assume it was not SELinux), then I tried anyway with SELinux disabled (setenforce 0 from the console before starting the graphical mode) and still the issue was there

Comment 23 scott 2017-08-29 04:43:26 UTC
hi -

Thanks.  I've also been bedeviled with long delays for various operations
after upgrading to 26, but didn't connect it with notifications until
i stumbled on this bug.

However, in addition to the messages mentioned above, i saw these:

Aug 29 00:03:48 karma dbus-daemon[2134]: [session uid=500 pid=2134] Activating service name='org.freedesktop.Notifications' requested by ':1.948' (uid=500 pid=19467 comm="notify-send Test I'm a test. " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug 29 00:04:47 karma plasma_waitforname: org.kde.knotifications: WaitForName: Service was not registered within timeout


which led me to

  https://bugs.kde.org/show_bug.cgi?id=381693

which has the actual explaination.  The problem is that in
/usr/share/dbus-1/services, we have both
org.kde.plasma.Notifications.service and
org.xfce.xfce4-notifyd.Notifications.service
providing the org.freedesktop.Notifications service.
In my case, i'm running xfce, but when dbus tries to start a notification
service, it uses the kde one.  This fails because kde isn't running.

Unfortunately, the kde folks closed this with WONTFIX, claiming that
it should be fixed in a future dbus version.

I can confirm that renaming away the file
/usr/share/dbus-1/services/org.kde.plasma.Notifications.service
makes notifications work again.

The difference seen above between whether notifications did or did not work
must come down to just the order in which the two files are listed in the
directory.  dbus must just be starting whichever one it encounters first.

Doing a

  dnf reinstall plasma-workspace

seemed to fix the problem.  Of course, notifications in kde may well be broken now,
but i don't generally use the kde desktop, so that's not such a big deal.

Comment 24 Ned 2017-08-29 06:55:57 UTC
hi

Thank you scott, you made my day !

After reading your post I searched in /usr/share/dbus-1/services files containing "Name=org.freedesktop.Notifications", and found org.kde.plasma.Notifications.service and org.freedesktop.mate.Notifications.service

I moved away org.kde.plasma.Notifications.service since I use Mate DE, logged off, logged in and my session opened in 2 seconds instead of 52 !

Comment 25 Ned 2017-08-29 21:10:07 UTC
(in addition to previous post, sorry, I was a bit short due to happiness)
I now have notifications working ok, and their appearance can be set normally in the control panel, and corresponding errors in journal disappeared.

Comment 26 Todd 2017-08-30 16:39:26 UTC
mv /usr/share/dbus-1/services/org.kde.plasma.Notifications.service /usr/share/dbus-1/services/org.kde.plasma.Notifications.service.000 

Worked beautifully.  It even got rid of the two minute wait the first time you lost a game in kpat and started a new game.  I did not even realize the two were related.

Thank you!!!!!

Comment 27 Todd 2017-09-29 03:00:31 UTC
Did a `dnf upgrade` on Fedora 26 and problem came back again.  But I was ready for it this time!

Fixed it with:

# rm /usr/share/dbus-1/services/org.kde.plasma.Notifications.service.000 
# mv /usr/share/dbus-1/services/org.kde.plasma.Notifications.service /usr/share/dbus-1/services/org.kde.plasma.Notifications.service.000

Comment 28 Todd 2017-11-17 21:43:30 UTC
This is still an issue in Fedora 27.  And the fix under comment 27 still works, but takes about 30 seconds to take hold.

Do you need to change the version to 27?

Comment 29 Todd 2018-02-10 06:23:37 UTC
On my initial FC27 machine install this is not an issue.

With my upgraded machine (now on FC27), every so often after a dnf upgrade, I have to move org.kde.plasma.Notifications.service again.

This is a real pain in the neck (not my ACTUAL word).  Would you guys please fix this?

Comment 30 Todd 2018-02-18 00:49:57 UTC
A clue to the puzzle:

Did an 

# rpm -qf /usr/share/dbus-1/services/org.kde.plasma.Notifications.service

And it showed the file owned by "plasma-workspace"

Then did an 

# dnf remove plasma-workspace

203 MB removed; 79 packages

Problem solved.

Now I will leave it to Red Hat to figure of why.

Comment 31 major 2018-03-31 17:04:14 UTC
A better workaround for the "org.freedesktop.Notifications" conflict between "org.kde.plasma.Notifications.service" and "org.xfce.xfce4-notifyd.Notifications.service" is as follows.

For all users:

# mkdir -p /usr/local/share/dbus-1/services
# ln -s /usr/share/dbus-1/services/org.kde.plasma.Notifications.service         /usr/local/share/dbus-1/services/org.kde.plasma.Notifications.service.DISABLE
# ln -s /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service /usr/local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service.DISABLE
# restorecon -Firv /usr/local/share/dbus-1

If KDE is preferred:
# mv /usr/local/share/dbus-1/services/org.kde.plasma.Notifications.service.DISABLE         /usr/local/share/dbus-1/services/org.kde.plasma.Notifications.service

If XFCE is preferred:
# mv /usr/local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service.DISABLE /usr/local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service


For a particular user:

$ mkdir -p ${HOME}/.local/share/dbus-1/services
$ ln -s /usr/share/dbus-1/services/org.kde.plasma.Notifications.service         ${HOME}/.local/share/dbus-1/services/org.kde.plasma.Notifications.service.DISABLE
$ ln -s /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service ${HOME}/.local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service.DISABLE
$ restorecon -Firv ${HOME}/.local/share/dbus-1

If KDE is preferred:
$ mv ${HOME}/.local/share/dbus-1/services/org.kde.plasma.Notifications.service.DISABLE         ${HOME}/.local/share/dbus-1/services/org.kde.plasma.Notifications.service

If XFCE is preferred:
$ mv ${HOME}/.local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service.DISABLE ${HOME}/.local/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service

Comment 32 Mauro Carvalho Chehab 2018-04-21 11:06:30 UTC
This bug is still present on Fedora 27.

Comment 33 Mauro Carvalho Chehab 2018-04-21 11:14:41 UTC
The most noticeable effect here is with nm-applet: every time an event happens there (a click to open its menu, a change from one wifi network to another, etc), it takes a lot of time to do any action. Only after dbus timing out, something happens.

In my case, my default desktop is mate, but sometimes I use plasma, when I need to take some snapshots from Kaffeine (with I maintain upstream).

The workaround of having a local/share/dbus-1 works on Fedora 27, but the real fix seems to be for the plasma notification service to be called only when the plasma desktop is running.

Comment 34 Steve Foster 2018-05-17 22:48:07 UTC
The exact same problem now exists F28. Same work around required. It bothers me greatly both KDE and Mate both seem to say upstream, not our issue. WHY DO WE BOTHER CREATING THE CORRECT DBUS Service file when it's to stupid to pick the correct Desktop service file. Seems like some folks have their heads up their arsenal all the way to their toes...

Comment 35 Jim Hines 2018-05-18 23:47:40 UTC
For me, this problem started when I first updated from F25 to F26 and continued with F27. The nm-applet is where I was irritated the most by it. I didn't really notice the pop up notifications missing too, but I kept seeing the dbus errors anyway. I was worried that removing the plasma-workspace would stop kde apps from running altogether, but it didn't. They still work fine without it. Thank you Scott! Now I won't have to worry about this when upgrading to Fedora 28. I wish someone would swat this damn bug!

Comment 36 Ben Cotton 2018-11-27 14:50:52 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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 27 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 37 scott 2018-11-28 05:51:02 UTC
Still observed in F28.

Comment 38 Ben Cotton 2018-11-30 17:32:10 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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.