https://bugs.kde.org/show_bug.cgi?id=460460
Bug ID: 460460
Summary: Baloo lies about its status when writing to its
database
Classification: Frameworks and Libraries
Product: frameworks-baloo
Version: 5.99.0
Platform: Archlinux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Baloo File Daemon
Assignee: baloo-bugs-n...@kde.org
Reporter: adam.m.fontenot+...@gmail.com
Target Milestone: ---
SUMMARY
I was encountering a separate issue with Baloo, probably
https://bugs.kde.org/show_bug.cgi?id=442453
I tried to check on Baloo's status - both in the System Setting UI and with
`balooctl status` - and it claimed to be idle. But it was clearly not idle, see
below.
STEPS TO REPRODUCE
1. Disable content indexing - only file indexing is relevant here.
2. Get into a situation where Baloo will choke on some files and start
thrashing the disk. In this case I had opened a large file with Audacity and
then closed the program, probably resulting in the deletion of some temporary
files. (See the linked bug above describing heavy disk write caused by file
deletion.)
3. Try to check on Baloo's status.
OBSERVED RESULT
`balooctl` takes a very long time (30 seconds or so) to respond (as does the
System Setting UI)... this System Settings freeze probably deserves a separate
bug report...
Eventually it responds and claims to be idle:
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 788,267
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 3.01 GiB
According to htop, however, `baloo_file` was using quite a lot of memory and an
increasing amount of CPU.
I remembered to try `strace` on the `baloo_file` process while this was
happening, and it was an endless stream of seeking and writing on a single file
descriptor. Almost certainly this file was the Baloo database, given the
concurrent index bloating.
EXPECTED RESULT
1. Baloo should respond quickly to status requests. The controller application
should never (?) be deadlocked.
2. Baloo should describe itself as "writing to database" or something similar
when it is performing these heavy database writes. 3. Baloo should allow the
user to kill it from the System UI when it is in *any* running state, even if
it is not actively indexing.
In the situation in question, Baloo had bloated its database from 0.5 GB to
over 3 GB in the space of about 2 minutes, so being able to kill it quickly is
critically important in this kind of situation.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Kernel Version: 6.0.1-arch1-1 (64-bit)
Graphics Platform: X11
--
You are receiving this mail because:
You are watching all bug changes.
