SUMMARY The Favorites in the Application Launcher don't show up after rebooting the system. If you look up the application and right click on it, you still have the option to remove from favorites. Clicking this doesn't change anything. If you look up an application you haven't favorited yet you can favorite it, and it shows up as expected until the next reboot. STEPS TO REPRODUCE 1. Have Favorites in Application Launcher or add applications as favorite 2. Reboot OBSERVED RESULT No favorites shown when opening the Application Launcher EXPECTED RESULT Favorites shown SOFTWARE/OS VERSIONS Operating System: CachyOS Linux KDE Plasma Version: 6.6.0 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.19.3-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 32 GiB of RAM (31.2 GiB usable) Graphics Processor: AMD Radeon RX 7900 XTX ADDITIONAL INFORMATION You can remove applications from favorites that no longer show up to re-add them with the following commands: $ systemctl --user stop plasma-kactivitymanagerd.service $ rm ~/.local/share/kactivitymanagerd/resources/database $ rm ~/.config/kactivitymanagerd-statsrc $ systemctl --user restart plasma-plasmashell.service $ systemctl --user start plasma-kactivitymanagerd.service
It also happened to me after upgrading to plasma 6.6.0 from 6.5.5 (OS: ArchLinux x86_64). Operating System: Arch Linux KDE Plasma Version: 6.6.0 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.18.9-arch1-2 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 32 GiB of RAM (31.2 GiB usable) Graphics Processor: AMD Radeon RX 7900 XT
(In reply to tesfabpel from comment #1) > It also happened to me after upgrading to plasma 6.6.0 from 6.5.5 (OS: > ArchLinux x86_64). It seems after a reboot, favorites are now shown again. I don't know what changed, maybe some issue on loading while migrating some data to a new version (I don't even know if it changed between 6.5.5 and 6.0.0)...
Did you by any chance install Plasma 6.6 and not reboot afterwards?
(In reply to Nate Graham from comment #3) > Did you by any chance install Plasma 6.6 and not reboot afterwards? I did reboot. I also checked the logs to be sure. It seems to be a one-off issue (at least for me, I can't talk about the other user) and it fixed itself the next reboot. ``` /var/log/pacman.log: 2026-02-21T12:06:58+0100 updraded a plasma package 2026-02-21T12:08:16+0100 end of pacman upgrade journalctl: feb 21 12:09:49 systemd-journald[666]: Journal stopped --- reboot --- feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 6488161 feb 21 12:12:07 tesx-pc plasmashell[1830]: ERROR: KSycoca database corruption! feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 6357106 feb 21 12:12:07 tesx-pc plasmashell[1830]: ERROR: KSycoca database corruption! feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 6619183 feb 21 12:12:07 tesx-pc plasmashell[1830]: ERROR: KSycoca database corruption! feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 6357108 feb 21 12:12:07 tesx-pc plasmashell[1830]: ERROR: KSycoca database corruption! feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 7536744 feb 21 12:12:07 tesx-pc plasmashell[1830]: QThread(0x562b1b98be20, name = "Qt mainThread") error detected in factory 0x562b1f9d04f0 feb 21 12:12:07 tesx-pc plasmashell[1830]: ERROR: KSycoca database corruption! feb 21 12:12:07 tesx-pc plasmashell[1830]: QBuffer::seek: Invalid pos: 7536744 (many more lines like this) feb 21 12:12:07 tesx-pc plasmashell[1830]: No ksycoca database available! Tried running kbuildsycoca6 ? (many many more lines like this) feb 21 12:12:14 tesx-pc plasmashell[1830]: Entry is not valid "systemsettings.desktop" 0x562b1c7bcfc0 feb 21 12:12:14 tesx-pc plasmashell[1830]: Entry is not valid "file:///usr/share/applications/systemsettings.desktop" 0x562b1c7bcfc0 feb 21 12:12:14 tesx-pc plasmashell[1830]: Entry is not valid "steam.desktop" 0x562b1c6f0a40 (many more lines like this) ```
Aha! > ERROR: KSycoca database corruption! > > No ksycoca database available! Tried running kbuildsycoca6 So the DB got corrupted, but was successfully rebuilt on reboot. https://invent.kde.org/frameworks/kservice/-/merge_requests/226 might help with this.
After 5-6 reboots it also works for me now. Seems like it fixes itself for everyone, should this be closed then?
The fact that it eventually self-heals is good, but it shouldn't break in the first place! So let's use the bug report to track that.
(In reply to Nate Graham from comment #7) > The fact that it eventually self-heals is good, but it shouldn't break in > the first place! So let's use the bug report to track that. Hi, I’m new here and I’m not very familiar with how things work yet, but I started experiencing this issue today. It’s strange because I installed Fedora KDE about a week ago and everything had been working perfectly. I retraced my steps and reviewed the changes I made before the issue started, and I noticed that the problem began right after installing JetBrains Toolbox. After disabling the “Launch Toolbox App at system startup” option and rebooting, the issue stopped occurring. The Favorites menu worked again and the icons no longer disappeared. However, if I manually open JetBrains Toolbox, the issue immediately returns. I’m not sure whether this is directly related, but the behavior seems consistent enough to be relevant.
Excellent information! I've managed to reproduce the problem sometimes. Alas, still no idea what exactly is causing the problem. Something inside our system cache gets corrupted so we start reading garbage and we fail to recover properly.
*** Bug 515909 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kservice/-/merge_requests/231
(In reply to ESΤΞBΛΝ from comment #8) > after installing JetBrains Toolbox. I also had this problem when using JetBrains IDEA EAP (only). After applying the changes form https://invent.kde.org/frameworks/kservice/-/merge_requests/231 and rebuilding kservice the problem is gone. So JetBrains IDEA was not the cause of the problem, it just triggered it.
I do not know if this is related but in my case, randomly when logging in, it would completely remove all task manager icons and the entire application menu flushed (and favourites disappeared), until I manually ran kbuildsycoca6 --noincremental. Then had to log in and out for the favourites to reappear (out of order).
This bug affects me too. I also use JetBrains Toolbox + GoLand 2026.1 EAP. KDE Neon + plasma 6.6.1. I hope that https://invent.kde.org/frameworks/kservice/-/merge_requests/231 will fix this bug. I am waiting for the merge and a new build to install this fix as soon as possible.
Git commit 2de8b433550f5614778394f441f6635769c9613f by Harald Sitter. Committed on 02/03/2026 at 07:25. Pushed by sitter into branch 'master'. ksycoca: do not allow for recursive repairs this is a mighty complicated issue. fiddling with kservice/ksycoca will trigger creation of KSycoca and KServiceFactory instances. eventually the call chains arrive in KSycocaFactory and move on to findFactory. findFactory performs a checkDatabase and that may auto-repair the database if it finds it to be out of date or broken. this then closes and reopens the database (a singleton by virtue of KSycoca being a singleton) and eventually issues databaseChanged. at this point an observant user may react to the database change and adopt the changes... by calling into kservice/ksycoca. A fatal problem. this produces a recursive call chain where we perform the entire factorization dance again. If now, and this is the tricky bit, anything caused another rebuild to be needed (e.g. a desktop file changing) then the database will get closed and opened again and now the outer call chain has a thrashed state (both call chains worked on the same singleton, mind, so closing it in the inner chain breaks the outter chain). a specific scenario of this is happening in plasma-nm where QRCA tech reacts to database changes with a service lookup, producing another database change, thrashing the state, and eventually cashing. to deal with this we simply emit database changes in a queued fashion. we really really really should simplify this framework! M +32 -1 autotests/kservicetest.cpp M +2 -1 autotests/kservicetest.h M +13 -0 src/services/kservicefactory.cpp M +12 -2 src/sycoca/ksycoca.cpp https://invent.kde.org/frameworks/kservice/-/commit/2de8b433550f5614778394f441f6635769c9613f
Git commit 3ec3e084db1005b34fd1debd73346ef6c79fe6da by Nicolas Fella, on behalf of Harald Sitter. Committed on 02/03/2026 at 15:17. Pushed by nicolasfella into branch 'Frameworks/6.23'. ksycoca: do not allow for recursive repairs this is a mighty complicated issue. fiddling with kservice/ksycoca will trigger creation of KSycoca and KServiceFactory instances. eventually the call chains arrive in KSycocaFactory and move on to findFactory. findFactory performs a checkDatabase and that may auto-repair the database if it finds it to be out of date or broken. this then closes and reopens the database (a singleton by virtue of KSycoca being a singleton) and eventually issues databaseChanged. at this point an observant user may react to the database change and adopt the changes... by calling into kservice/ksycoca. A fatal problem. this produces a recursive call chain where we perform the entire factorization dance again. If now, and this is the tricky bit, anything caused another rebuild to be needed (e.g. a desktop file changing) then the database will get closed and opened again and now the outer call chain has a thrashed state (both call chains worked on the same singleton, mind, so closing it in the inner chain breaks the outter chain). a specific scenario of this is happening in plasma-nm where QRCA tech reacts to database changes with a service lookup, producing another database change, thrashing the state, and eventually cashing. to deal with this we simply emit database changes in a queued fashion. we really really really should simplify this framework! (cherry picked from commit 2de8b433550f5614778394f441f6635769c9613f) M +32 -1 autotests/kservicetest.cpp M +2 -1 autotests/kservicetest.h M +13 -0 src/services/kservicefactory.cpp M +12 -2 src/sycoca/ksycoca.cpp https://invent.kde.org/frameworks/kservice/-/commit/3ec3e084db1005b34fd1debd73346ef6c79fe6da
*** Bug 514860 has been marked as a duplicate of this bug. ***
*** Bug 511469 has been marked as a duplicate of this bug. ***