19

As mentioned in this question and answer, baloo file extractor often randomly pops up in the background in KDE Plasma, and consumes a lot of CPU cycles.

The answer says that it is safe to disable baloo.

What does baloo do? Will it disable file search/extract features in dolphin if I disable baloo?

  • 2
    On a side note, it is not sufficient to kill baloo_file_extractor, it will spawn immediately again. The command to kill baloo seems to be: killall -9 baloo_file_extractor baloo_file baloorunner – robertspierre Jul 06 '23 at 04:07

2 Answers2

23

Baloo is part of the KDE Plasma desktop. Specifically, it is the file indexing and file search framework for KDE Plasma. Baloo is not an application, but a daemon to index files. Applications can use the Baloo framework to provide file search results. You can learn more about Baloo in the KDE Community Wiki.

Yes, you can safely remove or disable Baloo, but if you intend to search using KDE tools, you probably shouldn't.


As mentioned in the comments, it has been verified by OP that file search in Dolphin works after disabling Baloo, but file search in KRunner does not work anymore.


I'm glad that you linked to this question, because while it has a good top/accepted answer, I have issue with the question itself. The question implies that because the daemon uses background RAM, that the system runs slower, and therefore should be removed. This can become a slippery slope where one might want to start methodically disabling processes to get the RAM usage lower.

In fact, this is counterproductive because the opposite is usually true: daemons that perform tasks like search indexing and caching can dramatically increase the speed of search results when you call for them. There's a saying: "Unused RAM is wasted RAM". Unless your system is starved for RAM, I would not worry about processes using it, and would advise against disabling services for the reason of reducing RAM usage. The same is also generally true for CPU usage if it's happening in the background and not interfering with other processes.

Nmath
  • 12,744
  • For me it's not RAM, Baloo (sometimes, and randomly) uses 50%-80% CPU cycles of my quad core CPU (that is 100% in 2-3 cores) which makes the computer appear to be not responding/taking seconds to switch between windows. When this happens, I know Baloo started working, so I would open KSysGuard and kill baloo. – Archisman Panigrahi Aug 17 '20 at 08:02
  • "but if you intend to search using KDE tools" -- You mean file search inside menu or krunner? – Archisman Panigrahi Aug 17 '20 at 08:03
  • Any application that calls for it. Since it's part of KDE - my guess is every KDE application that has any kind of file search feature. It can also be configured: https://community.kde.org/Baloo/Configuration – Nmath Aug 17 '20 at 08:32
  • I can confirm that I can still search in Dolphin. File search in KRunner does not work anymore (which is fine). – Archisman Panigrahi Aug 20 '20 at 07:12
  • 2
    As an aside, Linux doesn't leave "unused" RAM to any degree, it is initially used for buffers/cache, so Baloo using significant memory may well reduce overall performance - although I do agree with the "unused ram is wasted" sentiment in general. – Graham Nicholls May 17 '21 at 18:43
  • I think there is an error in the official page on the "first run" is kinda confuse explanation, nosense: Official website: "This first run config value determines if Baloo has run through the entire file system and checked every file for indexing. If you ever delete the baloo db manually, this should be set to false so that baloo scans the entire file system tree again on startup." – Sergio Abreu Sep 22 '23 at 09:19
1

A quick look into the journal should show you what it is currently working on (among other log messages from your system):

$ journalctl --follow
baloo_file[3063]: kf.baloo: Batch finished
baloo_file_extractor[11002]: kf.baloo.engine: 110546205324801626 deleting "golang-github-unknwon-goconfig.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546209619768922 deleting "golang-github-tidwall-match.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546213914736218 deleting "golang-github-urfave-cli-2.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546218209703514 deleting "golang-github-tidwall-pretty.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546222504670810 deleting "golang-github-urfave-cli.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546226799638106 deleting "golang-github-tidwall-sjson.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546231094605402 deleting "golang-github-urfave-negroni.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546235389572698 deleting "golang-github-tinylib-msgp.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546239684539994 deleting "golang-github-viant-assertly.spec"
baloo_file_extractor[11002]: kf.baloo.engine: 110546243979507290 deleting "golang-github-tj-assert.spec"

It looks like it can take a lot of time and CPU cycles to update its index if you add or remove a lot of files. As a developer this can easily happen when unzipping a source code archive for example.

dreua
  • 946