SUMMARY In the system tray (in the task bar), the icon for system and application updates do not appear anymore. It is not simply hidden or not even in the disable icon list. It does not appear anywhere. There is no option to bring it back. It is very annoying as it is now impossible to be warned if there are updates without classical notifications or opening manually discover. Receive a notification is less piratical because there are invasive when they appear and then invisible as long as we don't click on the notification icon. It is impossible to differentiate update notifications from other notifications without opening notifications, while on the other hand, the update icon clearly indicates the situation about updates. And also if we watch the notification list to see if it is about updates, it make notifications content disappear when it close which is annoying if you don't deal with all notification content now. For those who don't want to be warned with an update icon, there was a setting option for that. For those who want to hide the icon in the "Show hidden icons" (which look like a "down arrow" in the task bar), it was an also an option. There is no options anymore. STEPS TO REPRODUCE 1. Watch in the task bar if the update icon appear. 2. Click on the "down" icon from system tray to see other icon shortcuts, and see if the update icon is here. 3. Clic on "configure system tray..." to find more options 4. In System Tray Settings > Entry : see if there is the update icon in the list. OBSERVED RESULT The bug is the update icon is nowhere. Not only it can't be see in the system tray to be used to see if there is update and used as a shortcut. It also can not be find or configured to reappear as normal. There is no option to bring the update icon back. EXPECTED RESULT The update icon should show in the system tray (I think it is a better default option for new users). If it is not the case by default , then it should be at least a option. The update icon should be in the "System Tray Settings" for users to choose what they want : "Always shown", "Shown when relevant", "Always hidden", "Disabled". It mean that it should back as before, or at least back in options with an other default option. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 5.19.0-41-generic (64-bit) Graphics Platform: Wayland
Created attachment 158944 [details] Screenshoot showing that there is no update icon in the system tray.
Created attachment 158945 [details] No update icon in the system tray setting, first part of the list.
Created attachment 158946 [details] No update icon in the system tray settings, second part of the list.
By not seeing updates I had very important bugs (making multiple application unusable) that stayed for weeks and I didn't realize that there were updates that fixed them. Not being up to date and not knowing about it is really bad for security and worse if we are stuck on a bad version full of bugs. As the update icon is much more convenient than the notifications and because update notifications always annoy me, I deactivated the update notifications and was looking if the update icon was here to see if there were any updates.
Can you try running DiscoverNotifier in a terminal window to see what happens? On my system it's located at /usr/libexec/DiscoverNotifier, but on your system it might be somewhere else; you can run `sudo find /usr/ -name DiscoverNotifier` to find where it lives on your system. Run it in a terminal window and paste all the text that appear in the window. Thanks!
(In reply to Nate Graham from comment #5) > Can you try running DiscoverNotifier in a terminal window to see what > happens? > > On my system it's located at /usr/libexec/DiscoverNotifier, but on your > system it might be somewhere else; you can run `sudo find /usr/ -name > DiscoverNotifier` to find where it lives on your system. Run it in a > terminal window and paste all the text that appear in the window. Thanks! My DiscoverNotifier is located in /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier. When I run '/usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier' in a terminal, I get nothing. It ends immediately with no return.
Created attachment 158980 [details] Running DiscoverNotifier in a terminal.
Interesting. Is DiscoverNotifier by any chance already running? Can you paste the output of `ps -ef | grep DiscoverNotifier`?
(In reply to Nate Graham from comment #8) > Interesting. Is DiscoverNotifier by any chance already running? Can you > paste the output of `ps -ef | grep DiscoverNotifier`? Yes. With `ps -ef | grep DiscoverNotifier`, I get : dim 2037 1787 0 13:40 ? 00:00:01 /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier dim 21472 21263 0 21:13 pts/1 00:00:00 grep --color=auto DiscoverNotifier
Ok, so it's already running. That's why running it again doesn't work; it's a single-instance app. Can you run the following terminal commands? > killall -9 DiscoverNotifier > /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier Then paste the contents of the terminal window and also see if it appears in the System tray's active area or its settings window.
(In reply to Nate Graham from comment #10) > Ok, so it's already running. That's why running it again doesn't work; it's > a single-instance app. > > Can you run the following terminal commands? > > > killall -9 DiscoverNotifier > > /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier > > Then paste the contents of the terminal window and also see if it appears in > the System tray's active area or its settings window. The kill command works. Then when I run '/usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier' it run without stopping or returning anything. It keeps running forever with no return, but it works and the update icon is back in the system tray like before the bug. So I have stopped it with ctrl+C (it disappear from the system tray) and then restarted with '/usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier &'. I get '[1] 22018' (no other return) and it is now running in the background and working in the system tray. Thank you for helping me. Now the question is : why does it not work with the first start made by the OS itself ? Each time I start the computer it doesn't work. Then how to fix it ? (To fix it I supposed there are two kind of fix : the good one which made things work like before, and the hacked one with additional instruction added at the start. I don't know what file to edit for the hacked solution, and if possible I would prefer a cleaner fix.)
At each reboot, DiscoverNotifier is running and not working. I have tested 'ps -ef | grep DiscoverNotifier' after a reboot (and no other command before) and I get : dim 1960 1712 1 22:29 ? 00:00:00 /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier dim 3024 2811 0 22:29 pts/1 00:00:00 grep --color=auto DiscoverNotifier It is the same process running and not working than the one working when starting it manually.
I guess maybe the process is started by the OS at a time when the OS is not able to handle the system tray, or maybe there is an error in the process that makes the first launch fail.
> Now the question is : why does it not work with the first start made by the OS itself ? Yep, that's what we need to figure out next. Let's see what it's doing on boot. Can you reboot and then paste the output of the following terminal commands? systemctl status --user app-org.kde.discover.notifier@autostart.service journalctl -b 0 --user-unit=app-org.kde.discover.notifier@autostart.service Thanks!
(In reply to Nate Graham from comment #14) > > Now the question is : why does it not work with the first start made by the OS itself ? > Yep, that's what we need to figure out next. > > Let's see what it's doing on boot. Can you reboot and then paste the output > of the following terminal commands? > > systemctl status --user app-org.kde.discover.notifier@autostart.service > > journalctl -b 0 --user-unit=app-org.kde.discover.notifier@autostart.service > > Thanks! For 'systemctl status --user app-org.kde.discover.notifier@autostart.service' I get : ● app-org.kde.discover.notifier@autostart.service - Discover Loaded: loaded (/etc/xdg/autostart/org.kde.discover.notifier.desktop; generated) Active: active (running) since Tue 2023-05-16 17:28:57 CEST; 2min 30s ago Docs: man:systemd-xdg-autostart-generator(8) Process: 1945 ExecCondition=/lib/systemd/systemd-xdg-autostart-condition KDE (code=exited, status=0/SUCCESS) Main PID: 1966 (DiscoverNotifie) Tasks: 9 (limit: 18927) Memory: 53.2M CPU: 480ms CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.discover.notifier@autostart.service └─1966 /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier mai 16 17:28:57 PC-fixe-Linux systemd[1703]: Starting Discover... mai 16 17:28:57 PC-fixe-Linux systemd[1703]: Started Discover. mai 16 17:29:23 PC-fixe-Linux DiscoverNotifier[1966]: kf.notifications: env says KDE is running but SNI unavailable -- check KDE_FULL_SESSION and XDG_CURRENT_DESKTOP For 'journalctl -b 0 --user-unit=app-org.kde.discover.notifier@autostart.service' I get : mai 16 17:28:57 PC-fixe-Linux systemd[1703]: Starting Discover... mai 16 17:28:57 PC-fixe-Linux systemd[1703]: Started Discover. mai 16 17:29:23 PC-fixe-Linux DiscoverNotifier[1966]: kf.notifications: env says KDE is running but SNI unavailable -- check KDE_FULL_SESSION and XDG_CURRENT_DESKTOP Thank you again.
Created attachment 159003 [details] Information (terminal) about DiscoverNotifier after a reboot.
Aha, that's helpful, thanks. > env says KDE is running but SNI unavailable -- check KDE_FULL_SESSION and XDG_CURRENT_DESKTOP So DiscoverNotifier is launching before SNI is up, ok. We're in this code: https://invent.kde.org/frameworks/knotifications/-/blob/master/src/kstatusnotifieritem.cpp#L975 The Notifier's .desktop file says: > X-KDE-autostart-phase=1 So the options for what could be happening are: - SNI is launched in phase 1 and they race - SNI launches using a different system that doesn't respect these phases and they race - SNI is not running at all Still trying to figure it out.
Oh, this is just another manifestation of Bug 425315. *** This bug has been marked as a duplicate of bug 425315 ***
(I can confirm that it has been fixed.)