| Summary: | Exploring Plasma Welcome Center > KRunner makes baloorunner consume 95+% CPU thereafter | ||
|---|---|---|---|
| Product: | [Applications] Welcome Center | Reporter: | skierpage <info> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | akselmo, nate, olib141 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
For me baloo doesn't spike, but it does appear in htop. Maybe good idea for this example to not invoke baloo related searches in the example. Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.11-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600 The fact that the mock KRunner actually searches your files is sort of intended, to showcase the file searching power of KRunner. Have you perhaps disabled baloo, masked its systemd service, or done anything else non-default vis-a-vis baloo? 🐛🧹 ⚠️ 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! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |
SUMMARY I run the Plasma Welcome Center and explored its panes. I noticed my laptop's fans turned on and stayed on, even after I exited the application. `top` showed baloorunner, which I think is the glue program that connects KRunner to file searching, consuming 98% of my CPU. STEPS TO REPRODUCE 0. Maybe you need to be using baloo for file indexing. I don't normally search for things from KRunner. 1. Run `top` in a terminal window 2. Start Welcome Center 3. Navigate to the third pane "Powerful When Needed" and click KRunner 4. Wait a minute, then navigate to another pane, then exit the Welcome Center application. 5. Press Alt-Space to bring up KRunner, type into its search box OBSERVED RESULT `baloorunner` shoots up in the process list to 95-98% of CPU depending on how busy your computer is. It was only using 2.9% of my memory. Its CPU usage stays high even when I stop looking at the KRunner details. Sometimes balorunner's CPU usage remained high even several minutes after I quit the Welcome Center application, and I had to kill it. baloorunner rises in `top` CPU usage if I type stuff into KRunner, but it doesn't hit 95%. EXPECTED RESULT Less CPU usage? SOFTWARE/OS VERSIONS Linux/KDE Plasma: in Fedora 43 beta KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION If I run plasma-welcome from a terminal, after a while it prints a lot of kf.runner: Error requesting matches; calling "org.kde.runners.baloo" : "org.freedesktop.DBus.Error.NoReply" "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." I ran strace on the baloorunner process and it's spending a lot of time attempting to access dozens of mime files like access("/var/lib/flatpak/exports/share/mime/text/x-scons.xml", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/var/lib/flatpak/exports/share/mime/text/x-scons.xml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) I only have files in /var/lib/flatpak/exports/share/mime/application/ for one flatpak app I installed (rosegarden), Then baloorunner will actually open a random file in my Documents area openat(AT_FDCWD, "/path/to/Documents/somefile", O_RDONLY|O_CLOEXEC) = 22 then it calls statx on it and reads it, then it goes back to access()/openat() 31 mime files. But this is I/O, not CPU bound.