https://bugs.kde.org/show_bug.cgi?id=487916
--- Comment #3 from tagwer...@innerjoin.org ---
(In reply to Sergio from comment #2)
It's interesting that it is "baloo_file" and not "baloo_file_extractor",
"baloo_file" is doing a scan through all your files to build a list of what's
new, what's changed and what needs to be done. That can be a lot of directory
lookups.
It may be that you are caught by an earlier change (related to BTRFSi, some
months back), for KF6
https://invent.kde.org/frameworks/baloo/-/merge_requests/131
and cherrypicked for KF5
https://invent.kde.org/frameworks/baloo/-/merge_requests/169
The original issue was that you could have files appearing multiple times in
the index, a "baloosearch -i one-of-your-files.txt" gave you a number of hits.
The patch meant that there would be an extra "reindex" but after that you're
fine (should be fine).
If you reboot now, has baloo_file done its work or does it still take time?
You can adjust the amount of RAM with
systemctl --user edit kde-baloo
and you can change the "MemoryHigh=512M" to something like "MemoryHigh=25%",
that will give Baloo more breathing room but not allow it to starve other
processes of memory. The 512MB might be too tight.
> Why does it say "disabled", though? If it is disabled why is it starting and
> how?
It's a good question and I've not got a good answer out of Google. I think it
might be being "wanted" by another service. There might be something useful in
Bug 481101
> 1. `balooctl6 suspend` seems to do nothing at all.
> 2. `balooctl6 disable` sets baloo to be disabled, but does not stop
> `baloo_file` at all.
These work "by asking" Baloo to stop rather than killing it. If Baloo is busy
it does not always listen :-/
A disable should stop it running next reboot, although Bug 481101 suggests that
something, somewhere might be reenabling it....
--
You are receiving this mail because:
You are watching all bug changes.
