Baloo/Debugging
Baloo is responsible for searching through files. Given that every system is quite different, and many different files can have different results, there can be some issues with Baloo. This page aims at helping you debug what exactly is going on and how to report the issue appropriately.
If you're in doubt, and not sure what is going on, please just file a bug and provide whatever information you feel may be appropriate. The developers will ask for more information and provide steps for you to follow.
Seeing debug output
The baloo and kfilemetadata code logs (selectively prints) informative messages that may be useful using Qt's logging facility. One way to turn on this logging (there are many others) is to create or modify the file $HOME/.config/QtProject/qtlogging.ini
and add the following lines
[Rules] kf.filemetadata=true kf.baloo=true
restart baloo and/or balooctl monitor and you will see these messages where log messages go on your system.
Baloo is consuming too much CPU / RAM / Disk IO ?
The Baloo Project is responsible for many different parts of KDE. The developers need to know exactly which component is problematic. It would be best if you checked what the offending process is called.
KSysGuard and Plasma System Monitor should be able to tell CPU, RAM and disk usage for baloo processes, but KSysGuard requires you to manually add disk usage columns.
baloo_file
This process is responsible for scheduling the indexing of files and save the name of the file. If this process is consuming too much CPU or Disk IO, it's probably due to the initial indexing. Based on your hard drive speed, baloo_file is able to do somewhere between 100 to 1000 files per second. Depending on how many files you have, it could take a couple of minutes. It would be best to just wait for a couple of minutes.
You can check which files are currently being scanned with balooctl monitor and the current indexing status with balooctl status.
If you feel that you have been waiting for quite some time, and the baloo_file process is still consuming too much CPU or disk IO, please file a bug.
Baloo does not find a file
If baloosearch or Dolphin Search > Content does not find a file that should be indexed, the rough steps to take in a terminal are
- balooctl status - is Baloo running?
- balooshow -x /path/to/file to see if Baloo knows about the file
- Check your Baloo configuration to make sure you have directed Baloo to index or not index that directory
- See if Baloo indexes a simple file in the same location:
- Run balooctl monitor
- Create a simple file, e.g. echo balooTestMe > /path/to/testfile.txt
- see if
testfile.txt
is indexed (baloosearch balooTestMe, try same steps above)
- If baloo does not, tell it to reindex with balooctl index /path/to/file
- Check the mime type of the file with kfilemeta
- Turn on debug info as described here.
- Clear the file from the index with balooctl clear /path/to/file and re-index it.
- ...
balooshow
balooshow prints debug information about a file.
$ balooshow /home/vishesh/file.jpg 4 /home/vishesh/file.jpg Width: 713 Height: 955 Photo X Dimension: 713 Photo X Dimension: 955
If baloosearch search terms does not find a file that should match, then run balooshow -x /path/to/file for the file which Baloo does not return. It should print information similar to what is being printed above, including the file information and terms in the file that Baloo should have indexed. If no information is printed, then please check the following
- The file is not in Baloo's list of exclude folders
- The baloo_file process is running.
Find by filename
balooshow -x displays additional information, including the terms that Dolphin's Find > by Filename search matches. For example,
$ balooshow -x path/to/日本国_déjà_γενεος.txt` ... File Name Terms: Fdeja Ftxt Fγενεος deja txtConfiguration γενεος
If you type more than one character in the Dolphin file browser's find by Filename field, it searches these terms anchored at the start, thus searching for "de", "γε", etc. should return this file.
baloosearch
The Baloosearch tool can be used to perform simple searches. Configuration
$ baloosearch fire 77040 /home/vishesh/kde5/src/qt5/qtimageformats/tests/shared/images/mng/fire.mng 237751 /home/vishesh/Videos/Catching Fire Epic Review Special Edition.mp4 237788 /home/vishesh/Videos/The Hunger Games Catching Fire (2013) [1080p] 237790 /home/vishesh/Videos/fire.mp4 53907 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/html/MediaController.cpp 54051 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/html/HTMLMediaElement.cpp 52257 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/platform/ThreadTimers.cpp 52867 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/loader/NavigationScheduler.cpp 53568 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/html/track/TrackListBase.cpp 52255 /home/vishesh/kde5/src/qt5/qtwebkit/Source/WebCore/platform/Timer.cpp
You should try searching for the file with this command.
If the file is not found even though it is indexed, then please file a bug with the exact search term, and the relevant words in the file.
General testing procedure
This procedure should provide you a cozy method to check if baloo is experiencing issues as well as files to attach to your bug reports. It assumes you have a single file that has failed indexing for whatever reason.
- Open two Konsole windows and tile one to the left (A) and the other to the right (B);
- On Konsole A, run
balooctl monitor | tee -a baloomon.txt
and leave it running, this should leave a log of a full index by the end of this procedure; - On Konsole B, run
balooctl status
You should get output like the following if everything has already been indexed and one file failed:
Baloo File Indexer is running Indexer state: Idle Total files indexed: 1.000 Files waiting for content indexing: 0 Files failed to index: 1 Current size of index is 10,00 MiB
- If you do have a failed file, run
balooctl failed | tee -a baloofailed.txt
to show which file has failed on your terminal and append it to a file named baloofailed.txt. Then, manually check the file path and runbalooshow /path/to/faulty/file | tee -a baloofailed.txt
to append the debug information about the file;
- On Konsole B, run
balooctl purge
;
- See if there's anything on Konsole A running the monitor tool that seems suspicious, like if it's staggering at the failing file;
- By the end, on Konsole B, run
balooctl status
again, and on Konsole A cancel the monitoring with Ctrl+C.
Is the file still failing to index? Then the issue is consistently reproducible, please report it over https://bugs.kde.org.
If the file is now indexing correctly, then it's not a consistently reproducible issue, but this might still indicate something to be worked on, requiring further reporting steps. Please report the issue over https://bugs.kde.org and follow any instructions the developers might ask of you.
Remember to attach the generated files on your bug report!
Indexing a file directly
Using the above technique you can copy or modify a problematic file and watch for errors. You can also run balooctl clear /path/to/problemfile
followed by balooctl index /path/to/problemfile
to force a reindex and possibly see additional debug output.
Determining content indexing duration
Here's a simple bash script to output and log the state and date of balooctl status immediately after purging the index in order to determine how fast your files get indexed:
#!/bin/bash
balooctl purge &>/dev/null
sleep 2
balooctl status | grep -B1 "indexing" | tee balootime.txt 2>/dev/null
date "+%T" | tee -a balootime.txt
while sleep 2; do
balooctl status | grep -B1 "indexing" | tee -a balootime.txt 2>/dev/null
date "+%T" | tee -a balootime.txt
done
What it does:
- Purges the database
- Fetches only the lines "Total files indexed" and "Files waiting for content indexing", redirecting standard output to a file named balootime.txt and removes standard error
- Prints that and the current time continuously every two seconds
Since it ends on a loop, you'll need to press Ctrl+C once "Files waiting for content indexing" reaches 0. If you have over 10,000 files, you may want to change the loop time to 5 to 15 seconds instead.
For a general comparison, on a machine with an SSD and 1559 files to be indexed, immediately after a purge, 4 seconds are required to index all files (going from 0 to 1559 instantly) and 35 seconds are required to index the content of all files. These values might be different for you depending on your machine's specs, the number of total files, and their format.
In case you think your indexing is taking more time than it should, please refer to the above general testing procedure to determine whether you should file a bug report.