Created attachment 187788 [details] Showing 5 simultaneous Discover processes (none of which produce a useable window or closeable instance on the taskbar). SUMMARY After booting up Solus, if I ever need to use Discover to manage my applications, and I think I'll ever need to use it again for the remainder of my PC's time running, I cannot close Discover again. If I do, I will not be able to open it back up before rebooting. STEPS TO REPRODUCE 1. Start up PC, sign in (my OS is Solus) 2. Open Discover. Use it or don't use it -- doesn't matter. 3. Close Discover. 4. Try to open Discover again: from the taskbar, from the start menu, whatever manner. It will fail to open. OBSERVED RESULT Not only does Discover fail to reopen, but in the System Monitor, we can see that it opens up a new Discover process every single time we try to open it, and they remain forever, stacking up. EXPECTED RESULT If the application worked properly, after closing Discover, it would be easy, trivial to reopen it with a click on any of the places to find it (taskbar, start menu...). Furthermore, it would not keep spinning up new processes that get permanently stuck. SOFTWARE/OS VERSIONS Solus Linux: 4.8 Opportunity Budgie UI: 10.9.4 ADDITIONAL INFORMATION Kernel: Linux 6.17.8-324.current An existing bug report, 375804, has been made for this issue. However, it was automatically closed because of the unresponsive bug report author. I will do what I can to help this issue get fixed, though I am not very knowledgeable. The last message to the author in that thread was about running Discover through GDB. I do not know how to do that, so please let me know (if that is even the right thing to do here). The existing bug report was filed for Discover version 5.8.5, making this a fairly old issue. In the attached image, you can see the 5 simultaneous Discover processes (none of which produce a useable window or closeable instance on the taskbar).
Is this issue reproducible for you? It happens at every login? If so, can you run `plasma-discover --backends packagekit,flatpak,fwupd` and then quit the app and see if the issue still happens? I'm suspecting it *will not* happen. If that's correct, then do it again with `plasma-discover --backends packagekit,flatpak,fwupd,kns` and quit the app and see if it still happens. I'm suspecting that it *will* happen.
(In reply to Nate Graham from comment #1) > Is this issue reproducible for you? It happens at every login? > > If so, can you run `plasma-discover --backends packagekit,flatpak,fwupd` and > then quit the app and see if the issue still happens? I'm suspecting it > *will not* happen. > > If that's correct, then do it again with `plasma-discover --backends > packagekit,flatpak,fwupd,kns` and quit the app and see if it still happens. > I'm suspecting that it *will* happen. Yes, it is reproducible, every single login. I followed your instructions and the app still failed. I'm adding a new attachment for these commands. In the first attempt, which was run while Discover was open, something seems to have happened, but despite your theory, it did not prevent the issue from happening. The future attempts were made in the same boot and you can see they did not resolve in any manner at all, and had to be forcefully terminated.
Created attachment 187806 [details] Bugged results of running recommended commands.
Any new thoughts? I just want to make sure my update didn't slip through the cracks.
I got the email about it; you'll just need to be a bit patient, especially around the end of the year when lots of folks are on vacation. I do understand how frustrating this must be, but the good news is that since you can reproduce it 100% of the time, that will make the debugging simpler.
The holidays are quite understandable! This was all I needed to hear, it's not urgent (I don't need to install software every single day).
(In reply to Nate Graham from comment #1) > Is this issue reproducible for you? It happens at every login? > > If so, can you run `plasma-discover --backends packagekit,flatpak,fwupd` and > then quit the app and see if the issue still happens? I'm suspecting it > *will not* happen. > > If that's correct, then do it again with `plasma-discover --backends > packagekit,flatpak,fwupd,kns` and quit the app and see if it still happens. > I'm suspecting that it *will* happen. Okay, so by some coincidence while discussing in another thread for Solus bugs, someone pitched me a similar command, and I ran it. Shockingly, Discover *did* open. The line they gave me was `plasma-discover --backends packagekit,snap,fwupd,flatpak`. I wondered why it was the case, and I noticed "snap" in there. I removed that term, and... it STILL opened. But that was weird, because that's the same as your first suggestion... Turns out, no, it's NOT the same as your first suggestion. The order of operations actually matters. `fwupd,flatpak` succeeded, but your `flatpak,fwupd` *failed*. The order of those two items matters (it seems to be because flatpak is dependent on fwupd -- it's not because flatpak has to go last specifically, because I was able to add the `kns` from your second suggestion to the end and it still ran). This bug is not over, though. That's because even after using that function, closing and trying to reopen Discover still fails (it only succeeds when I use the command line to send the valid types of commands where flatpak comes after fwupd). What this tells me is that the Discover shortcut on the taskbar is programmed to call one of the invalid types. It could probably be fixed simply by swapping it out for one of the valid commands, but that wouldn't answer the big question: What exactly breaks in the invalid ones, given that they always work the first time? Clearly, they are not invalid by their general nature, but because something changed. And knowing that would answer the question of why the order of `flatpak` and `fwupd` matters. Maybe `fwupd` (which sounds like an update or some kind of daemon) cleans up some stuff before flatpak initializes? The first run leaves something unclean when closing, so only wiping it *before* running again fixes that. I have absolutely no idea how this actually works (I have been in college for both IT and programming, so I have technical literacy, but that doesn't extend to knowing what any of these applications are made off on a logical level and what kinds of handshakes they make and what dependencies they have). But it is a very strong lead in my opinion. To draw something else (aside from "why does it break in the first place") back into focus: As mentioned, even after running the "valid" commands, despite how I can run them successfully as many times as I want, it never fixes the issue with clicking the icon, so closing the app after it's been opened in ANY manner leaves it broken. Also, something else you may want to know, since you suggested two options, one with "kns" and one without, expecting different results: Any command `plasma-discover --backends packagekit,fwupd,flatpak` works, even if we append `,kns` or `,snap` or `,kns,snap` or `,snap,kns` onto it. The extra terms have no bearing on the success or failure of any methods, nor the ability to reopen the app.
Extra note: When I start installations in Discover through this command line manner, there is no install progress menu in the bottom left corner like there usually would be.
Some separate info that is not related to the crashes but someone should probably investigate while we're here. When I use `,snap` or `,kns` anywhere in the list, although they don't impact the success or failure of opening the Discover app, they do BOTH have their own error in the logging output that looks important... ``` org.kde.plasma.libdiscover: Couldn't find the backend: "kns-backend" among QList("packagekit-backend", "kns-backend", "flatpak-backend", "fwupd-backend") org.kde.plasma.libdiscover: Plugin "snap-backend" doesn't have the right IID "" expected org.kde.discover.6.5.4.AbstractResourcesBackendFactory ``` To reiterate, these do not prevent the app from launching -- they sure look like issues, though, although I don't have the knowledge to grasp the consequences. Maybe I've found precisely why you through your second line would fail for me (while the first one was supposed to succeed), because you found that kns one in your JournalCTL? It just turns out that if it causes an issue, this is not the one.
This looks like bug 507217, I'll merge this report into that one. Please follow the other report for updates. It does have developer work started on it. Thanks. *** This bug has been marked as a duplicate of bug 507217 ***
(In reply to TraceyC from comment #10) > This looks like bug 507217, I'll merge this report into that one. Please > follow the other report for updates. It does have developer work started on > it. Thanks. > > *** This bug has been marked as a duplicate of bug 507217 *** Ken in the other thread has determined that this issue here is not a duplicate of the issue he says he resolved in the thread you connected. Where can we find help for this issue here?
So, to be clear: `plasma-discover --backends fwupd,flatpak` works `plasma-discover --backends flatpak,fwups` fails is that correct?
(In reply to Nate Graham from comment #12) > So, to be clear: > > `plasma-discover --backends fwupd,flatpak` works > > `plasma-discover --backends flatpak,fwups` fails > > is that correct? That is correct. That leads me to believe that fwupd is a dependency of some aspect of flatpak (or that due to some bug, it's acting like it it when it shouldn't be), and that in turn leads me to believe the GUI icon for Discover is set up to internally run with that non-functional flatpak,fwupd order.
Fascinating! I can't reproduce it myself on KDE Linux, though. `plasma-discover --backends flatpak,fwupd` works fine and doesn't block when quitting.
> That is correct. That leads me to believe that fwupd is a dependency of some > aspect of flatpak (or that due to some bug, it's acting like it it when it > shouldn't be), and that in turn leads me to believe the GUI icon for > Discover is set up to internally run with that non-functional flatpak,fwupd > order. The icon for Discover is set up with this invocation line on Solus, it is not set to specify the backends: Program: plasma-discover Command-line arguments: %F I had been hesitant to say this is Solus specific, but after testing other distros, it does appear that way. I'll close this and open an issue with Solus with the details of my troubleshooting there. Testing on the laptop where I can reproduce this: - Starting Discover from the icon produces no journal logs other than the Started line, which is normal - Starting with `plasma-discover --backends fwupd,flatpak` does not bring up the GUI, this shows up in logs after a few moments Jan 06 11:51:45 tracey-solus-aura plasma-discover[144476]: Failed to register name 'org.kde.discover' with DBUS - does this process have permission to use the name, and do no other processes own it already? Jan 06 11:51:45 tracey-solus-aura systemd[1862]: app-org.kde.discover@d7464020b8b943689b948ded66956f6c.service: Main process exited, code=exited, status=1/FAILURE Jan 06 11:51:45 tracey-solus-aura systemd[1862]: app-org.kde.discover@d7464020b8b943689b948ded66956f6c.service: Failed with result 'exit-code'. - Starting with `plasma-discover --backends fwupd,flatpak` also does not bring up the GUI, same errors - Starting with `plasma-discover --backends flatpak-backend,fwupd-backend` (these are the backends actually listed in --listbackends), no GUI, same errors - Starting with `plasma-discover --backends fwupd-backend,flatpak-backend`, GUI appears This is output on cli $ ~ plasma-discover --backends fwupd-backend,flatpak-backend org.kde.plasma.libdiscover: Plugin "fwupd-backend" doesn't have the right IID "org.kde.discover.6.5.4.AbstractResourcesBackendFactory" expected org.kde.discover.CDDtESsCnLIRnIU0.AbstractResourcesBackendFactory org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: true This is in logs Jan 06 12:18:58 tracey-solus-aura plasma-discover[288708]: libostree pull from 'flathub' for appstream2/x86_64 complete Jan 06 12:18:58 tracey-solus-aura plasma-discover[288708]: /var/tmp/flatpak-cache-GI6EI3/repo-JW3Tcz: Pulled appstream2/x86_64 from flathub Jan 06 12:20:47 tracey-solus-aura DiscoverNotifier[2570]: started unattended update QDateTime(2026-01-06 18:20:47.663 UTC Qt::UTC) I tested with other distros, with updates set to be manually applied, after rebooting. There were no problems regardless of backend order - Fedora - (no snap backend on the VM) OK - Neon Testing - OK - OpenSuse Tumbleweed (which also uses appstream) - OK
Thank you. It is interesting that the backend order is not always relevant in your testing, despite how it seems for me. Would you be able to drop the link for the Solus issue here so I can follow it for updates?
(In reply to platos.shutters from comment #16) > Thank you. It is interesting that the backend order is not always relevant > in your testing, despite how it seems for me. Would you be able to drop the > link for the Solus issue here so I can follow it for updates? Check the URL in this report.