SUMMARY After updating KDE Neon to Plasma 6.5.1 I no longer get the update notification entry in system tray. It is not just hidden, it is not there at all. Seems to affect other users on different distributions, e.g. https://discuss.kde.org/t/plasma-6-5-plasma-discover-discover-notifier-no-more-icon-in-systray/41195 links to a Debian bug report with similar observations. Can not yet confirm whether removing the empty config file (and restarting the service) as suggested in those references works as there are currently no pending updates. There is a (closed) report with similar symptoms https://bugs.kde.org/show_bug.cgi?id=434241 STEPS TO REPRODUCE So far not a clear path. Those who encounter the issue report to have an empty PlasmaDiscoverUpdates config file. OBSERVED RESULT No update icon shown in system tray nor part of the hidden entries not listed in "Entries" in the system tray config screen. EXPECTED RESULT Update notifier icon shown when there are updates. SOFTWARE/OS VERSIONS Operating System: KDE neon User Edition KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.14.0-34-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION
Seems the setting/timestamp was migrated to $XDG_STATE_HOME/discovernotifierstaterc Current value is last Monday (2025-10-27) but I did not get any visual cue when the 6.5.1 package became available. Update interval is set to "daily"
Is it crashing on launch, maybe? I'm seeing that myself in Bug 511602.
For me it seems to run stably since I restarted it manually with systemctl kevin@hephaistos ~ % systemctl --user status app-org.kde.discover.notifier@autostart.service ● app-org.kde.discover.notifier@autostart.service - Discover Loaded: loaded (/etc/xdg/autostart/org.kde.discover.notifier.desktop; generated) Active: active (running) since Sun 2025-11-02 10:18:09 CET; 1 day 22h ago Docs: man:systemd-xdg-autostart-generator(8) Process: 12402 ExecCondition=/usr/lib/systemd/systemd-xdg-autostart-condition KDE (code=exited, status=0/SUCCESS) Main PID: 12404 (DiscoverNotifie) Tasks: 14 (limit: 76884) Memory: 28.6M (peak: 29.9M) CPU: 4.124s CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.discover.notifier@autostart.service └─12404 /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier --check-delay 20 I've manually checked with Discover's main app to see if there are any updates but currently there are none. So I don't know yet if the removal of the (old?) config file + restart changed anything
The icon has now appeared. Clicking the icon launches Discover but it gets stuck in Fetching updates (stuck as in doesn't complete in ~10 minutes). Will check again later. I also have a second user account which has not seen login since update to 6.5.0 so it still has the old config and time stamp within and the new state file does not exist yet. Might have time later today to check if it show the indicator for today's updates and how the two files get changed
I had time for a bit more testing. Later on Wednesday I had to restart my session (actually reboot), resulting again in update icon missing. Since the stored timestamp at this point was the same day this was probably intentional. However, it has not reappeared on any of the days since. I also checked with a second user account that still had the old state file. Logging in did remove the value from the old state file (leaving it empty) and did show the icon, as well as writing a new time stamp into the new state file. On the main account I needed to restart app-org.kde.discover.notifier@autostart.service for it to show the icon again. My guess is that the the service does either not recheck once it has notified about updates or that it does not use the value configured for "Notification Interval" in Discover's main UI.
I have the impression that, once the notification is sent, it waits the delay set in "Notification interval", in my case 60*60*24, no matter what happens. This is the case if I logout/login or if updates arrive in the meantime. I solved the problem by moving the timestamp back more than a day and removing write permissions from the discovernotifierstaterc file. This way I'm alerted if updates arrive and if I log out and back in.
Is it maybe related to 511602?
Nate linked to that earlier already but I am not seeing any crash. According to systemctl status it has been running since the start of the session and I am pretty sure it will continue to do so until next time I logout or restart. I just restarted it and it did notify me about the pending updates (last update on Saturday evening) and only now it shows the icon again. Restarting it another time and the icon is gone.
I have now stopped the systemd unit and restarted it manually in a shell with debug logging enabled QT_LOGGING_RULES=org.kde.*.debug=true /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier --check-delay 20 :( org.kde.plasma.discover.notifier: Not triggering, state is DiscoverNotifier::NoUpdates org.kde.plasma.discover.notifier: refreshUnattended: not notifying about updates org.kde.plasma.discover.notifier: updateStatusNotifier: hasUpdates false hasSecurityUpdates false org.kde.plasma.libdiscover.backend.packagekit: using... PackageKit::Transaction(0x624d62a4c5b0) "/4697_edeadbeb" org.kde.plasma.discover.notifier: updateStatusNotifier: hasUpdates true hasSecurityUpdates false org.kde.plasma.discover.notifier: Not triggering, earliestNextTriggerTime is QDateTime(2025-11-11 17:37:09.827 UTC Qt::TimeZone UTC ) org.kde.plasma.discover.notifier: showUpdatesNotification: not notifying about updates org.kde.plasma.discover.notifier: refreshUnattended: useUnattendedUpdates false isOnline true isConnectionAdequate true So at least the problem at startup is not the missing check but the timestamp comparison. Which is should probably not do on startup otherwise logging out and logging in again loses UI state. Will keep this running until Wednesday when at least one interval check should have happened
from NotifierItem.cpp ----------------------------------------------------------------------------------------------- case DiscoverNotifier::NormalUpdates: { // Only show the status notifier on next notification time // BUG: 466693 ....... ....... ----------------------------------------------------------------------------------------------- https://invent.kde.org/plasma/discover/-/merge_requests/886 https://bugs.kde.org/show_bug.cgi?id=466693
Updated to 6.5.2 on the weekend and got the icon earlier this week (at which time I installed some but not all updates) and again today. Still, I wonder if the tray icon should count as "notification" (i.e. transient), IMHO it displays state.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
So is the issue fixed now? What's the current status? Sorry, I'm having a hard time following it.
It seemed to work again the week before last week but failed again last week. I think the problem is that the logic to suppress notifications is also applied to the icon but the icon. The notification is an event, the icon is state. It makes sense to not trigger the event again for a given period unless the state changes significantly, e.g. new security updates available, but the state needs to visualized at its current level. I.e. the icon is "hidden" when there are no updates but "visible" when there are any, regardless of whether they are normal or security related. Otherwise that information (state visual) is lost when the session (or just the service) restarts.
IIRC it's intentional that the tray icon is suppressed when the notification is suppressed. Both are supposed to honor the value of the update check interval setting in System Settings > Updates. If that's not working, then there's a bug; if it is working, then I think this is working as expected.
At the moment the icon does neither work as a notification nor as a status indicator. If it were a notification it would be gone when clicked, I've seen the update in Discover and decided not to react to it. If it were a status indicator it would still be there when I log out and log in again. Right now it does neither. Given that almost every other icon in the tray is a status indicator, I find it strange that this one should behave like a notification. And unlike any other notification not show up as a popup and not be accessible in the notification history. I am likely missing some important piece of information.
Created attachment 187509 [details] Suggested behavior as a state diagram I've attached a state diagram in an attempt to try to explain what I think should be the behavior. We have three states and several transitions. * Each state has an associated icon (or no icon). * Each transition might trigger a notification or might have the notification suppressed/silenced I think transition T4 is the one people do not want to trigger notifications. Maybe T5 as well. We could even enable users to disable all notifications, like most of our other apps do.
That's accurate. But it's missing one part: the T1 and T2 transitions are supposed to respect the update check frequency in System Settings > Updates. It isn't even supposed to *look* for updates more frequently than configured there.
There should be a frequency=always. This way, the status icon is always in the systray when needed. I simulate this behavior by removing write permissions on the discovernotifierstaterc file.
(In reply to Nate Graham from comment #18) > That's accurate. But it's missing one part: the T1 and T2 transitions are > supposed to respect the update check frequency in System Settings > Updates. Yes, maybe that is also intended. Main point is that the icon needs to be updated when a new state is entered, regardless of whether the transition triggers a notification or not. > It isn't even supposed to *look* for updates more frequently than configured > there. That might even get rid of the "last notification" timestamp.
Based on all the investigation and debugging so far, is it clear to you which exact circumstances/config file keys/etc cause this to happen? Since I can't reproduce it, I think we need to nail down specific steps to reproduce to make this actionable.
The easiest way to reproduce this is to restart the service (simulating session logout/login) once the status icon is shown. 1. Verify that the status icon is shown 2. Verify that the timestamp in `.local/state/discovernotifierstaterc` is less than your "update interval" old (in my case less than 24h) 3. systemctl --user restart app-org.kde.discover.notifier@autostart.service Expected: Status icon indicating that there are updates Observed: No icon As luca pointed out in https://bugs.kde.org/show_bug.cgi?id=511499#c10 the issue seems to have been introduced by a workaround for a bug report about checks happening too often. Given the multiple backends this is probably difficult to actually fix, so there was an attempt to hide this or mitigate the UI "noise" by remembering the last time the user was notified about updates. However, the check is accidentally applied against the status not the notification. I.e. the check is in `NotifierItem::shouldShowStatusNotifier()` when it should probably be in `DiscoverNotifier::notifyAboutUpdates()`, `DiscoverNotifier::showUpdatesNotification()` or `DiscoverNotifier::showDiscoverUpdates()` (these seem to be the places that deal with the actual notification, not the status/state)