Bug 469755

Summary: DiscoverNotifier can launch when SNI is not running
Product: [Applications] Discover Reporter: Dilam <pasdabonnements>
Component: NotifierAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aleixpol, kdelibs-bugs, nate, nicolas.fella
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Screenshoot showing that there is no update icon in the system tray.
No update icon in the system tray setting, first part of the list.
No update icon in the system tray settings, second part of the list.
Running DiscoverNotifier in a terminal.
Information (terminal) about DiscoverNotifier after a reboot.

Description Dilam 2023-05-14 17:08:20 UTC 
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
Comment 1 Dilam 2023-05-14 17:10:04 UTC 
Created attachment 158944 [details]
Screenshoot showing that there is no update icon in the system tray.
Comment 2 Dilam 2023-05-14 17:11:07 UTC 
Created attachment 158945 [details]
No update icon in the system tray setting, first part of the list.
Comment 3 Dilam 2023-05-14 17:12:19 UTC 
Created attachment 158946 [details]
No update icon in the system tray settings, second part of the list.
Comment 4 Dilam 2023-05-14 17:26:15 UTC 
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.
Comment 5 Nate Graham 2023-05-15 17:59:05 UTC 
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!
Comment 6 Dilam 2023-05-15 19:02:53 UTC 
(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.
Comment 7 Dilam 2023-05-15 19:04:02 UTC 
Created attachment 158980 [details]
Running DiscoverNotifier in a terminal.
Comment 8 Nate Graham 2023-05-15 19:07:37 UTC 
Interesting. Is DiscoverNotifier by any chance already running? Can you paste the output of `ps -ef | grep DiscoverNotifier`?
Comment 9 Dilam 2023-05-15 19:15:11 UTC 
(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
Comment 10 Nate Graham 2023-05-15 19:24:30 UTC 
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.
Comment 11 Dilam 2023-05-15 19:43:20 UTC 
(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.)
Comment 12 Dilam 2023-05-15 20:34:03 UTC 
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.
Comment 13 Dilam 2023-05-15 20:38:24 UTC 
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.
Comment 14 Nate Graham 2023-05-16 14:00:07 UTC 
> 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!
Comment 15 Dilam 2023-05-16 15:36:18 UTC 
(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.
Comment 16 Dilam 2023-05-16 15:37:30 UTC 
Created attachment 159003 [details]
Information (terminal) about DiscoverNotifier after a reboot.
Comment 17 Nate Graham 2023-05-16 16:46:31 UTC 
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.
Comment 18 Nate Graham 2023-05-17 00:43:44 UTC 
Oh, this is just another manifestation of Bug 425315.

*** This bug has been marked as a duplicate of bug 425315 ***
Comment 19 Dilam 2024-04-09 19:33:03 UTC 
(I can confirm that it has been fixed.)