497419 2024-12-13 18:07:35 +0000 plasma-discover process stays in background after pressing Ctrl+Q 2026-08-25 10:17:56 +0000 1 1 2 Applications Discover discover 6.2.4 Other Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=507217 NOR normal --- 1 cyber+kde plasma-bugs-null aleixpol kdedev LionsSharks15 nate taras.oleksyn https://invent.kde.org/plasma/discover/-/commit/6bb252afbfef7bc413824ee153285e498b669801 6.6.2 0 oldest_to_newest 2381062 0 cyber+kde 2024-12-13 18:07:35 +0000 SUMMARY Discover can take considerable amount of RAM (up to 600M), and I'd like to quit it after finishing upgrades. STEPS TO REPRODUCE 1. Discover autostarts with Plasma 2. Press Ctrl+Q OBSERVED RESULT "plasma-discover" process stays in background. EXPECTED RESULT Discover quits. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.17 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.3 Kernel Version: 6.12.1-gentoo (64-bit) Graphics Platform: Wayland Processors: 8 × AMD FX-8320E Eight-Core Processor Memory: 11.6 ГиБ of RAM Graphics Processor: NVD9 2381091 1 nate 2024-12-13 18:47:13 +0000 This would be expected if it's quit while updating, but then it's supposed to quit once it's finished. You also said "Discover autostarts with Plasma". This is only expected if you're manually set it up to do so, or if it was open at logout. Are you able to reproduce the bug if you launch Discover normally and then quit it with Ctrl+Q? Or only after it was autostarted at login? 2381096 2 cyber+kde 2024-12-13 18:54:07 +0000 (In reply to Nate Graham from comment #1) > You also said "Discover autostarts with Plasma". This is only expected if > you're manually set it up to do so, or if it was open at logout. Ah, I probably launched it via DiscoverNotifier update notification. > Are you able to reproduce the bug if you launch Discover normally and then > quit it with Ctrl+Q? Or only after it was autostarted at login? The plasma-discover process stays running in both cases. 2382533 3 nate 2024-12-18 18:36:37 +0000 Can you try again with a newer version of KDE Frameworks? I see you're using 6.7. Try 6.9 and see if that helps; it had some fixed for similar issues in KNewStuff, which Discover uses. 2382555 4 cyber+kde 2024-12-18 19:19:07 +0000 I'm using stable-keyworded framework releases, so I'll wait until keywords are updated in Gentoo and let you know. 2386119 5 bug-janitor 2025-01-02 03:47:31 +0000 🐛🧹 ⚠️ 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! 2390414 6 bug-janitor 2025-01-17 03:48:08 +0000 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. 2394488 7 cyber+kde 2025-02-02 15:43:39 +0000 I've updated to KDE Frameworks 6.9.0 and Plasma 6.2.5 and still need to kill `plasma-discover` manually after quitting the main window. Operating System: Gentoo Linux 2.17 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.5-gentoo (64-bit) Graphics Platform: Wayland Processors: 8 × AMD FX-8320E Eight-Core Processor Memory: 11.6 ГиБ of RAM Graphics Processor: NVD9 2394490 8 cyber+kde 2025-02-02 15:49:14 +0000 I can try debugging it myself with some guidance. 2459290 9 cyber+kde 2025-10-03 09:16:51 +0000 Still not fixed. Operating System: Gentoo Linux 2.18 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.2 Kernel Version: 6.15.11-gentoo (64-bit) Graphics Platform: Wayland Processors: 8 × AMD FX-8320E Eight-Core Processor Memory: 12 GiB of RAM (11.6 GiB usable) Graphics Processor: AMD REDWOOD 2499621 10 LionsSharks15 2026-03-01 23:32:29 +0000 Issue exists for me as well. I can't open Plasma Discover sporadically because a plasma-discover process is already running, and the only way to resolve the issue is to run "kill plasma-discover" (I do this through KRunner). Some info to help you debug, if I try to run this program through the terminal while a process is already running, I get the following outputs: QThreadStorage: entry 2 destroyed before end of thread 0x56279d187b30 QThreadStorage: entry 1 destroyed before end of thread 0x56279d187b30 I experienced this issue on both Debian 13 KDE (6.3.6-1) and Fedora 43 (6.6.1) 2502269 11 kdedev 2026-03-10 17:40:18 +0000 I'm not able to reproduce this on Plasma 6.6.2. After quitting Discover with Ctrl+Q, the process exits I'm going to mark this resolved. If anyone sees this on 6.6.2 or later, feel free to reopen this report. 2502741 12 LionsSharks15 2026-03-12 08:12:45 +0000 (In reply to TraceyC from comment #11) > I'm not able to reproduce this on Plasma 6.6.2. After quitting Discover with > Ctrl+Q, the process exits > I'm going to mark this resolved. If anyone sees this on 6.6.2 or later, feel > free to reopen this report. Sorry but I am still experiencing this issue on Fedora 43 with Discover v6.6.2 so I must reopen. I've tried closing using the titlebar button and Control + Q, neither close the problematic lingering processes. Any guidance to help debug this would be appreciate. I'm willing to help in any way to get to the root of this issue. 2523959 13 LionsSharks15 2026-06-17 20:03:10 +0000 (In reply to Serena Star from comment #12) > (In reply to TraceyC from comment #11) > > I'm not able to reproduce this on Plasma 6.6.2. After quitting Discover with > > Ctrl+Q, the process exits > > I'm going to mark this resolved. If anyone sees this on 6.6.2 or later, feel > > free to reopen this report. > > Sorry but I am still experiencing this issue on Fedora 43 with Discover > v6.6.2 so I must reopen. I've tried closing using the titlebar button and > Control + Q, neither close the problematic lingering processes. Any guidance > to help debug this would be appreciate. I'm willing to help in any way to > get to the root of this issue. Issue still present in Discover 6.7.0, Plasma 6.7.0, Frameworks 6.27.0, Qt 6.11.1 2526475 14 kdedev 2026-06-24 20:27:02 +0000 Can you let us know the output of this command? plasma-discover --listbackends 2527236 15 LionsSharks15 2026-06-27 00:28:04 +0000 (In reply to TraceyC from comment #14) > Can you let us know the output of this command? > > plasma-discover --listbackends Sure thing: Available backends: * flatpak-backend * kns-backend * packagekit-backend * fwupd-backend 2529301 16 taras.oleksyn 2026-07-05 03:15:49 +0000 This one might be a duplicate of https://bugs.kde.org/show_bug.cgi?id=522245. 2529316 17 cyber+kde 2026-07-05 05:19:44 +0000 (In reply to TraceyC from comment #14) > Can you let us know the output of this command? > > plasma-discover --listbackends Available backends: * kns-backend * flatpak-backend 2529324 18 cyber+kde 2026-07-05 05:29:23 +0000 (In reply to Taras Oleksyn from comment #16) > This one might be a duplicate of https://bugs.kde.org/show_bug.cgi?id=522245. Yes, they are very similar. > The process stays alive in the background, and a new discover window cannot be opened until that background process is manually killed. When I first reported this bug that wasn't the case, although now (as of Plasma 6.6.5) a new Discover windows fails to open unless I kill the background process manually. $ plasma-discover QThreadStorage: entry 2 destroyed before end of thread 0x555b75abe800 QThreadStorage: entry 1 destroyed before end of thread 0x555b75abe800 Also for me it doesn't matter whether some loading is happening. I can reproduce this bug if I quit after finishing updates. 2530275 19 nate 2026-07-08 22:37:07 +0000 https://invent.kde.org/plasma/discover/-/merge_requests/1355 might fix this. 2538983 20 bug-janitor 2026-08-14 16:54:42 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1393 2539122 21 olib141 2026-08-15 14:10:18 +0000 Git commit a8b5538958594d90406aa0294d3934bcd06e7607 by Oliver Beard, on behalf of Aleix Pol. Committed on 15/08/2026 at 14:03. Pushed by olib into branch 'master'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 522245, bug 522815, bug 518264 M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/a8b5538958594d90406aa0294d3934bcd06e7607 2539129 22 olib141 2026-08-15 14:31:34 +0000 Git commit 0d0a1d35c715838f585590d54a1a9d5b14cbd151 by Oliver Beard. Committed on 15/08/2026 at 14:11. Pushed by olib into branch 'Plasma/6.7'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 522245, bug 522815, bug 518264 (cherry picked from commit a8b5538958594d90406aa0294d3934bcd06e7607) Co-authored-by: Aleix Pol <aleixpol@kde.org> M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/0d0a1d35c715838f585590d54a1a9d5b14cbd151 2541661 23 olib141 2026-08-25 10:17:56 +0000 Git commit 6bb252afbfef7bc413824ee153285e498b669801 by Oliver Beard. Committed on 15/08/2026 at 14:10. Pushed by olib into branch 'Plasma/6.6'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 522245, bug 522815, bug 518264 (cherry picked from commit a8b5538958594d90406aa0294d3934bcd06e7607) Co-authored-by: Aleix Pol <aleixpol@kde.org> M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/6bb252afbfef7bc413824ee153285e498b669801