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
ooops, sorry. $ rpm -qa \*libnotify\* libnotify-0.7.7-2.fc26.x86_64
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.
More info: `dnf reinstall libnotify` made no difference
This bug is wrecking havoc on a lot of stuff. Is there any data or troubleshooting I can do to help?
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.
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
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 ...
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.
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
Sorry - meant to say that on a fresh F26 install it *does* work for me, but not on the upgraded system.
Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=785583
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
... 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
(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.
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.
would a strace notify-send test test be helpful?
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
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
Just out of curiosity, what is your selinux level: $ getenforce
$ 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)
(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
... 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
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.
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 !
(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.
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!!!!!
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
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?
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?
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.
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
This bug is still present on Fedora 27.
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.
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...
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!
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.
Still observed in F28.
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.