Bug 384372

Just while indexing, or forever? Does it go away if you restart it (`balooctl restart`)? Does it start immediately on startup, every time?

High CPU is very long until I shut down my computer at night. At least longer than 10 hours.

Restart it won't reduce CPU usage. It take up 12% CPU immediately after restarting.

Every time I restart my system, baloo_file_extractor uses the same amount of CPU after I enter the desktop for a while (maybe one ~ three minutes?).

I have the same issue. baloo_file_extractor consumes 100% on one of my CPU cores. If I kill the service and restart, it consumes again 100%. But this issue is new to me, maybe since Frameworks 5.40 or any other recent change.

Arch Linux
KDE Frameworks 5.40
KDE Applications 17.11.80
Plasma 5.11.3
Qt 5.10 beta 4 (compiled against 5.9.2)

(In reply to Rainer Finke from comment #3)
> I have the same issue. baloo_file_extractor consumes 100% on one of my CPU
> cores. If I kill the service and restart, it consumes again 100%. But this
> issue is new to me, maybe since Frameworks 5.40 or any other recent change.

I can confirm. It startet doing that just recently.
Arch Linux
KDE Frameworks 5.40
Plasma 5.11.4

Same problem here. Wonder why no one can give a working fix for it, aside form removing its service completely (at least so it seems to me).
The baloo_file_extractor process consumes a single core completely (100%). Gladly this thing is not multi-threaded, since it might take up all available cores then. bfe goes up with starting the system (e.g. from hibernation) and never goes down until killed manually.

A lot of people seem to struggle with this issue. I wonder how many cpu cores on this planet are senselessly sucking up electricity, executing the indexer, and producing nothing usable but heat.

configuration:
OpenSuse leap 42.3
KDE (plasmashell -v yields) 5.8.7
baloo 5.32.0-1.3-x86_64

There are some real-world consequences beside the annoying sound of the fans spinning up and down cooling this mess. Ever thought about the CO2 footprint?

It probably depends on the files it tries to index. I think there is a way to monitor which files it currently reads, but I am no expert with baloo.

I agree with Christoph probably there's a file somewhere  baloo_file_extractor can't handle.

Try this to find it:
$ balooctl stop

ensure neither baloo_file nor baloo_file_extractor are running

on a second command line enter
$ balooctl monitor (Do not hit return, yet)

on the first command line
$balooctl start (Hit return)

As quickly as possible hit return on the second command line

With a little luck balooctl monitor will report the files currently indexed.
The last reported file might be the culprit. Examine it and report your findings please.

In case this does not work, you can try balooctl disable/enable instead of stop/start. BEWARE this will rebuild your database from the scratch, which is time consuming and maybe not what you want to do.

(In reply to Michael Heidelbach from comment #7)
Thanks, Michael, for your advice.
I assume the command 'balooctl stop' is intended to stop baloo_file_extractor in the first place.
> Try this to find it:
> $ balooctl stop
> 
> ensure neither baloo_file nor baloo_file_extractor are running

baloo_file_extractor does neither stop nor show any other reaction after 'balooctl stop' - baloo_file_search is not running. I guess that playing around with the following options makes no sense then.

Or may I kill baloo_file_extractor manually?

Killing the process(es) manually lets balooctl report the dying service: 'Baloo died'.
I killed the baloo_file_extractor process, and deleted the index and the index-lock files from ~/.local/share/baloo, then did 'balooctl start'. The file extractor showd up in the task list with 13% cpu (a full core in an 8-core machine).

After some time, at the terminal where I started balooctl, a message was printed

org.kde.baloo: true "/org/kde/fstab///SWIDC010/MyD"
org.kde.baloo: true "/org/kde/fstab///192.168.2.6/userhome/heinrich"

which obviously refers to two mounted cifs drives that are (by default?) excluded from search. Above message is printed repeatedly from time to time.

My home directory is sized about 32GB, and after about 45 min of shuffling around, the index has round about 1.4GB.

It seems to have ended for now, there is a process baloo_file, baloo_file_extractor is gone, at index' size of 1.5 GB.

For the first time since installing 42.3 the indexer remains quiet. Could it have been the deletion of the index files? What about the newly created index, sized 1.5G for some 30GB user data - is that to be exepcted or is that just too big?

Regards
Heinrich

@Heinrich Seebauer: Problem solved, I think.

Great! Should we dupe this to a bug that tracks baloo hanging and burning CPU time when attempting to index certain files, or use this to track that?

Or is it another bug in play?

Deleting ~/.local/share/balooIndex* and restarting baloo is essentially the same as 
  $ balooctl disable
  $ balooctl enable

After that the database is rebuilt from the scratch. 
As reported in Comment 8 this sometimes solves the problem.

But, if we don't know the file that caused the trouble, we can't learn from that. :)

@Nate: I think it's a dupe.

Great, of which bug?

(In reply to Nate Graham from comment #12)
> Great, of which bug?

BUG:380456 Comment 2 looks similar. But please don't mark it as duplicate.
I need to read the bugs (and baloo's code) thoroughly before I can say anything about it.
I'd really like to get a hand at some files that cause trouble. Maybe baloo is just choking.

(In reply to Michael Heidelbach from comment #13)
If it's a file that utlimately causes the indexer's behaviour, shouldn't I expect it to occur again when I start indexing (i.e. call 'balooctl start')?

In my case it did not run endlessly anymore after deleting the index.
I would conclude that, having not changed anything in the setup or the indexed data sets, it might take more than a single file to provoke this behaviour.

If the indexer runs amok again, I will compile me a debuggable version, and attach gdb to the running process. Maybe one could tell then where it's looping undefinitely.

Thanks for your kind support
Heinrich

There are already a number of resource limitations in place for baloo, but I wonder if they cover all thinkable situations: When on a multicore system one core is more or less idle, and baloo happens to run on this otherwise idle core, is it possible there is nothing to really limit baloo's CPU consumption?

As far as I understand, *nice* is without effect in such situations, and baloo will get as much CPU time as it wants, if necessary 100% with all the annoying side effects (heat, fan speed going up, noise).

If that conclusion is right, wouldn't setrlimit() be a remedy?

No Baloo expert here either, but if you want to know the file it indexes right now, try it with

$ qdbus org.kde.baloo /fileindexer org.kde.baloo.fileindexer.currentFile

Today I had this again that baloorunner consumed 100% of one core of my CPU. For now I have deactivated the search again. Plasma 5.12.3, KDE Frameworks 5.44.

Don't know if the issues are the same, just for reference:

* An old topic on KDE forum with a whopping 65000 visits, the most recent posts are maybe relevant: https://forum.kde.org/viewtopic.php?f=154&t=120468

* A fix mentioned in this topic: https://phabricator.kde.org/D12335

Yes, it's almost certainly the same issue that was recently fixed. Thanks for following up!

*** This bug has been marked as a duplicate of bug 378754 ***