SUMMARY When an arbitrary number of icons exist in the user's icon paths, a several second stall will occur when adding or removing even a single (empty) file from /usr/share/icons or the user's .local icon directory. The mouse remains functional but the display is frozen. The system recovers shortly, but the disruption to one's work is complete. My investigation has led me to ~/.cache/icon-cache.kcache as a culprit STEPS TO REPRODUCE 1. Have a good number of icons in /usr/share/icons. I.e. the tela-icon-theme aur package has a lot 2. Install or remove this package alternatively, with tela-icon-theme installed (also able to reproduce at times with just breeze, oxygen and adwaita): touch /usr/share/icons/foo rm /usr/share/icons/foo OBSERVED RESULT When critical mass is observed, adding or changing even a single file in the icon directory results in a several second hang. It appears the ~/.cache/icon-cache.kcache file is being updated in this time and this update is the cause of the hangs. This makes sense as to why even removing files from the system results in hangs, it's less the IO of the icon adding process but the resulting cache update done by plasma. EXPECTED RESULT The icon cache to be updated without disrupting the user's experience SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux 6.6.1 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION NVMe m.2 1TB disk is on the FS, AMD 5900x processor I can only reproduce the hangs in plasma desktop. I cannot replicate a hang if doing the same action on a different tty without plasma loaded or over ssh. In fact, I can easily continue to watch things like htop, iotop etc over ssh all while my desktop is frozen. I originally suspected some feature of btrfs to blame, but I cannot mitigate the issue with the use of any: - disabling zstd compression - disabling cow (and therefore compression) - symlinking ~/.cache/icon-cache.kcache to a file on an ext4 SSD (bypassing btrfs completely) However, I did discover the following mitigations to the freezes: - symlink the icon-cache.kcache file to /dev/shm - change the ownership of icon-cache.kcache to root: to prevent the system from updating the cache file during changes to this directory. Hence, I'm quite certain the issue lies in some process that could be made a bit nicer during the cache update process. It seems the update is happening on the same thread as UI functions and ends up blocking updates to the graphical session.
IIRC we watch this path and run kbuildsycoca{5,6} in response to changes. Cannot personally reproduce the issue with `sudo touch /usr/share/icons/foo`.
I think it may get worse/easier to trigger with lots of icons to cache. I was able to pretty reliably trigger this with the Tela icons theme Aur package (the one which includes every color variation) -- it's probably 10s of thousands of icons in that full set. Simply installing and uninstalling the package causes full hangs on each operation with my setup. With the package in the installed state, the `touch foo` would reproduce the behavior every time. I was messing around with Bazzite (based on Kinoite) and it was harder to trigger there with the base set of icons but did eventually manage to reproduce the behavior with repeated touch/rm . I will dig a bit into kbuildsycoca -- it sounds like the right process given the manual description
I just updated to the 6.0 beta and can no longer reproduce the issue -- it seems icon-cache.kcache is no longer being generated/used? If so, I think there may not be much value in keeping this open; however, iirc, 5.27 is supposed to be a LTS version. That said, I wouldn't call this bug a showstopper, more an annoyance that would disappear with time as folks begin to upgrade to newer versions.
Heh, no wonder I couldn't reproduce the issue on Plasma 6. I did some gigging and this got fixed a few months ago for Plasma 6, yeah!