| Summary: | Discover fails to completely close on quit, remains open in the background, and doesn't start via a GUI method - SNAP,KNS | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | kenwgreen |
| Component: | KNewStuff Backend | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 4wy78uwh, aleixpol, kdedev, leinir, nate, platos.shutters, postix, sitter |
| Priority: | HI | ||
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| URL: | https://discuss.kde.org/t/plasma-discover-not-launching/12503/30 | ||
| Latest Commit: | https://invent.kde.org/plasma/discover/-/commit/e72da261565c391fcb89e42c67e354ee4f973297 | Version Fixed/Implemented In: | 6.6.0 |
| Sentry Crash Report: | |||
| Attachments: | Screenshot showing a first stuck Discover process taking more RAM than all the others | ||
|
Description
kenwgreen
2025-07-19 06:07:44 UTC
I've been seeing this on git-master on one laptop, but not in git-master or 6.4.3 on another laptop, both with Solus. Other Solus users have run into it https://github.com/getsolus/packages/issues/5623 We noticed that if Discover doesn't launch from the menu, it has a process in the process tree but no gui If launched from command line with no arguments, there are no errors The GUI can be launched if one or more backends are passed in on command line e.g. plasma-discover --backends packagekit-backend --backends flatpak-backend Probably knewstuff acting up again. Will need to find a way to reproduce and track down why it actually gets stuck. :( I have been playing with Discover and the backend addons. I have found that uninstalling Discover-Snap backend addon that the Discover app launches every time without fail. I only have to remove the Snap addon leaving the Flatpak and PackageKit addons installed,so it would appear there is some issue with Discover and the Snap backend *** Bug 510390 has been marked as a duplicate of this bug. *** There's some debugging info in Bug 510390. Would anyone be able to try this change? It would help us by printing if there's any outstanding Transactions that are never resolving themselves. https://invent.kde.org/plasma/discover/-/merge_requests/1194 I see harald suggested that it might be KNS but it seems snap might be related too. (In reply to Aleix Pol from comment #7) > Would anyone be able to try this change? It would help us by printing if > there's any outstanding Transactions that are never resolving themselves. Would be difficult to confirm without a consistent reproduction method. > I see harald suggested that it might be KNS but it seems snap might be > related too. I've definitely not ever had Snap installed, yet have experienced this, so it's not the *sole* cause, if so. Fair enough, maybe it's both. Some people have claimed to be able to reproduce the issue reliably following the links. (In reply to Aleix Pol from comment #9) > Fair enough, maybe it's both. > > Some people have claimed to be able to reproduce the issue reliably > following the links. Absolutely I can reproduce and indeed just to confirm I have as at the date and time of this reply;- 1. Open Discover 2. Re-installed Snap back-end via Discover. 3. Closed Discover 4. Tried to re-open without success. 5. $ pkill discover 6. $ plasma-discover --backends packagekit-backend 7. Uninstalled Snap back-end 8. Open Discover, no issue 9. Close and re-open Discover no issue Conclusion Discover Snap Backend is the issue. A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1196 Any of the people who can reproduce the issue, we'd very much appreciate some testing. Alternatively, could you see if the process ends after about 80s of closing it? Tried after re-installing Snap-Backend, waited 80 seconds I assume, still the Discover app failed to load. Un-installed the snap-backend and Discover launched no issue. *** Bug 513569 has been marked as a duplicate of this bug. *** Since my issue has been merged with this one and we appear to very much want testing from people facing this issues, I will copy my lengthy results here (including a quote of the recommendation I was given on my issue). See further comments below. (In reply to Nate Graham https://bugs.kde.org/show_bug.cgi?id=513569#c1) > 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. ============================== End of my comments on the duplicate issue. (In reply to Aleix Pol from comment #12) > Any of the people who can reproduce the issue, we'd very much appreciate > some testing. > > Alternatively, could you see if the process ends after about 80s of closing > it? My processes all disappear with time, but that amount of time is highly chaotic (out of order from the time the process threads are initialized). The first thread I try to make (aka the first time I try to click the icon to open after closing it), it creates a process that never decays to shutting down. That process is unique in the amount of memory it takes up. It is consistently just over 40MB, while any other Discover process spawned while the first one is sitting there (failing to open anything) only takes up ~32MB. Clearly, duplicate Discover processes are somehow different from that first attempted reopening, regardless that none of them work. I will attach an image to this issue showing the different RAM usage for the duplicates when I open excessive (stuck) instances. Anyway, to repeat, the time it takes for those 32MB excess processes to shut down is highly chaotic, some taking just a dozen seconds and some taking multiple whole minutes. Created attachment 188069 [details]
Screenshot showing a first stuck Discover process taking more RAM than all the others
I have not tried any Snap uninstalls or reinstallations, but based on my command line testing, the inclusion or lack of the Snap backend seems irrelevant (same for KNS). I noted this bug resolved on my config per my last post to this issue, although I cannot find it in this thread. If you have only been testing for this bug recently then sure I expect you may not have experienced it because as I reported as of my latest Ubuntu update I have successfully reloaded the SNAP-BACKEND and Discover works fine. My config is as follows;- Operating System: Ubuntu 25.10 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.2 Kernel Version: 6.17.0-8-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i7-6500U CPU @ 2.50GHz Memory: 9 GB of RAM (7.7 GB usable) Graphics Processor 1: Intel® HD Graphics 520 Graphics Processor 2: llvmpipe Manufacturer: Dell Inc. Product Name: Inspiron 5559 I can try with a... reloaded or reinstalled Snap backend or whatever, just tell me what to do, but given that Snap is not relevant to success or failure when running Discover from a command line, I can't imagine it could be the core cause of the issue here. (In reply to platos.shutters from comment #21) > I can try with a... reloaded or reinstalled Snap backend or whatever, just > tell me what to do, but given that Snap is not relevant to success or > failure when running Discover from a command line, I can't imagine it could > be the core cause of the issue here. Sorry but if you are having issue with Discover running it from the command line, using Terminal I assume, then I suggest you open another thread because my issue was running Discover from the KDE desktop, NOT the command line in terminal. (In reply to kenwgreen from comment #22) > (In reply to platos.shutters from comment #21) > > I can try with a... reloaded or reinstalled Snap backend or whatever, just > > tell me what to do, but given that Snap is not relevant to success or > > failure when running Discover from a command line, I can't imagine it could > > be the core cause of the issue here. > > Sorry but if you are having issue with Discover running it from the command > line, using Terminal I assume, then I suggest you open another thread > because my issue was running Discover from the KDE desktop, NOT the command > line in terminal. I'm not sure how you got that impression. Please read all of the notes that I added to the thread. I am using the command line for diagnostics, but only because I am having the issue of running Discover from GUI. What my comments are saying is that likely the issues in running from command line is likely the same as the issues running from GUI. > ... likely the same as the issues running from GUI.
Here is my first cause for reasoning (mentioned in my block of added information already, but worth repeating): If the JournalCTL debug line `org.kde.plasma.libdiscover: Couldn't find the backend: "kns-backend" among QList("packagekit-backend", "kns-backend", "flatpak-backend", "fwupd-backend")`, which has a list in no particular sorted order (alphabetic, reverse alphabetic), implies that opening Discover from GUI is using that order (`plasma-discover --backends packagekit,kns,flatpak,fwupd`) in the underlying mechanics, that means that it is set up using a problematic order of operations (it should be fwupd before flatpak). Otherwise, if the order of fwupd and flatpak shouldn't be dependent, then that means that this bug comes with a problem that affects command-line calling of Discover as well, which prevents that order of arguments from being used. Either way, the issue is not resolved.
That's OK and like I said if you are still have some other issues with Discover then I suggest you open another bug report detailing what your issues is, because as of the last Ubuntu update, my issue with Discover not re-executing at the desktop with SNAP-BACKEND installed was resolved and the reason why I have reported my original bug as such. If you have a problem with my dropping my diagnostic information in here, take it up with @TraceyC who merged thread 513569 with this one -- ideally after reading that issue thread so you can determine whether they were right to do this. I wasn't the one who requested my issue to be merged. Merry Christmas dude,,,, don't break the keyboard and good luck with your bug (In reply to kenwgreen from comment #27) > Merry Christmas dude,,,, don't break the keyboard and good luck with your bug Why are you coming across angry? I am being told by two different experts who know more than me two opposing things: one that my issue is the same, and the other that my issue is different. Why should I not be feeling lost and confused about that? I understand the pressures of being a contributor on a large project and not being responsible for every problem, but this approach is hurtful. (In reply to platos.shutters from comment #23) > (In reply to kenwgreen from comment #22) > > > (In reply to platos.shutters from comment #21) > > > > I can try with a... reloaded or reinstalled Snap backend or whatever, just > > > tell me what to do, but given that Snap is not relevant to success or > > > failure when running Discover from a command line, I can't imagine it could > > > be the core cause of the issue here. > > > > Sorry but if you are having issue with Discover running it from the command > > line, using Terminal I assume, then I suggest you open another thread > > because my issue was running Discover from the KDE desktop, NOT the command > > line in terminal. > > I'm not sure how you got that impression. Please read all of the notes that > I added to the thread. I am using the command line for diagnostics, but only > because I am having the issue of running Discover from GUI. What my comments > are saying is that likely the issues in running from command line is likely > the same as the issues running from GUI. I'll err on agreeing with Platos, because, as stated in https://bugs.kde.org/show_bug.cgi?id=507217#c8, https://bugs.kde.org/show_bug.cgi?id=510390#c4 demonstrates that this occurs even without Snap installed. I do want to apologize for not realizing that all my copied blocks of comments from the other thread didn't actually include the context by which there are terminal diagnostics to try to fix the GUI issue. I realize now that I did only mention the GUI in the comment #17 below it. I suppose based on the fact that my thread was marked as a duplicate and a message about that was created here for that, I assumed prematurely that my timing with that system message would make it self-evident without needing to explain the context for my command line diagnostics (after all, I figured, surely if any context is missing, they'd just go to the linked thread). But given that I offloaded a bunch of information, that more reasonable assumption might be that I actually did say everything important, so since I didn't mention the GUI in the pasted material, it would look like my problem isn't a GUI problem. I am sorry for leading that misunderstanding. To reiterate, what I posted was diagnostic work recommended to me by someone in my thread about fixing my Discover issues when closing and reopening through the start menu/taskbar. Multiple people asked me to perform things on the command line to see if my problems would get fixed, so I performed several tests to increase the amount of information and reduce the amount of back-and-forth. All my tests mentioned in the pasted material come with the given that I tried clicking the taskbar icon after every attempted fix. It was redundant to mention, however, in the actual thread this came from. I didn't fully consider the loss of context here. So again, I do apologize for that, Ken. In any case, it seems that Roke who had also been brought into this thread, as he has just mentioned, has Snap as an irrelevant factor to their otherwise identical symptoms. It feels fair to assume that there is a root issue that impacts both things, and the Snap reinstallation only hides it. At the very least, it would only be responsible to rule it out rigorously. A coincidence of multiple slightly different issues bubbling over time, that all have the same symptom of the GUI not opening after being closed the first time, being all actually caused by a different core issue seems deeply unlikely. We should find the core cause to fix it for good. And for this, I believe my extensive command-line testing may supply some important context going forward (even though the matter is initializing through the GUI). I need to confirm something, from those who might know. If I base myself on Windows experience, icons we click in the start menu and on the taskbar are actually shortcuts that call an executable in a defined manner, such as with libraries or using particular arguments. Basically, GUI operations ARE command-line operations, covered in a pretty wrapper. And I assume that in Solus (and Linux in general), this is the same. So as a ramp onto maybe solving this issue, I wanted to refer to my testing that found that having flatpak BEFORE fwupd in the argument order of the command fails after the first openings. This implies the GUI interaction is calling a command with that argument order -- something that we don't actually know for sure, but that contributors can likely check and prove or disprove. It would be an easy way to move onto that next suspicion. I have no experience contributing here and have no idea how I would verify this myself. Hence why I had made my bug report with my original thread. Is there a chance we can check this real quick? This bug and bug 513569 are getting muddled. I'd like to clarify the difference between them so we can investigate and fix both of them cleanly. Both are describing the symptom of the Discover GUI not appearing when the icon is clicked, but there are different things going on under the hood. This bug had discussed the Snap and KNS backends. Bug 513569 is about the GUI not starting if the flatpak backend is passed before the fwupd backend. Snap is not involved. Let's keep this bug focused on Snap and KNS. Let's also keep things respectful and friendly. Thanks. I'm setting this back to ASSIGNED since there's an open MR to fix the snap part https://invent.kde.org/plasma/discover/-/merge_requests/1196 Git commit e46cdcba93c280ca29b406ceb8a294741bf5e4c4 by Nate Graham, on behalf of Aleix Pol. Committed on 29/01/2026 at 15:58. Pushed by ngraham into branch 'master'. snap: Reduce thread waiting timeout There's no good reason to wait so much and much less for so long-time. M +1 -1 libdiscover/backends/SnapBackend/SnapBackend.cpp https://invent.kde.org/plasma/discover/-/commit/e46cdcba93c280ca29b406ceb8a294741bf5e4c4 Git commit e72da261565c391fcb89e42c67e354ee4f973297 by Nate Graham. Committed on 29/01/2026 at 16:17. Pushed by ngraham into branch 'Plasma/6.6'. snap: Reduce thread waiting timeout There's no good reason to wait so much and much less for so long-time. (cherry picked from commit e46cdcba93c280ca29b406ceb8a294741bf5e4c4) Co-authored-by: Aleix Pol <aleixpol@kde.org> M +1 -1 libdiscover/backends/SnapBackend/SnapBackend.cpp https://invent.kde.org/plasma/discover/-/commit/e72da261565c391fcb89e42c67e354ee4f973297 |