SUMMARY `baloo_file`/`Enable File Search` can't be permanently disabled. STEPS TO REPRODUCE 1. Go into `File Search` in KDE settings 2. Tick to disable `Enable File Search` and click Apply 3. Reboot 4. Notice that `baloo_file` is chewing through CPU and I/O resources. 5. Go back into `File Search` in KDE settings 6. Notice that `Enable File Search` has been re-enabled. OBSERVED RESULT `baloo_file` continues to run, consuming CPU and I/O. EXPECTED RESULT `baloo_file` should be permanently disabled and the `Enable File Search` should not be automagically re-enabled. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux/KDE Plasma KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION 1. `systemctl --user disable kde-baloo.service` doesn't help. It still starts up again at reboot. 2. Deleting the index after disabling `Enable File Search` makes no difference. 2. I need to disable `baloo_file` as my system is using `BTRFS` COW with scheduled snapshots enabled. This causes `baloo_file` to re-index every time a new snapshot is created, consuming large amounts of CPU and doing a lot of fs reads (slowing other opartions down) and performing writes that negatively impact SSD wear.
(In reply to MarkW from comment #0) > `baloo_file` should be permanently disabled and the `Enable File Search` > should not be automagically re-enabled. There has to be something else messing with it, this is not the usual behaviour... If it is disabled it generally stays disabled, and you can see the option in the .config/baloofilerc file as [Basic Settings] Indexing-Enabled=false Keep an eye on this, see if it is being changed back. You could try setting the config to "read only"... > 1. `systemctl --user disable kde-baloo.service` doesn't help. It still > starts up again at reboot. I'll check to see whether this does anything more than the "balooctl disable". I think not as it would not set the "indexing-enabled-false" > 2. Deleting the index after disabling `Enable File Search` makes no > difference. No, that would be a purge and you'd start again. > 3. I need to disable `baloo_file` as my system is using `BTRFS` COW with > scheduled snapshots enabled. This causes `baloo_file` to re-index every time > a new snapshot is created, consuming large amounts of CPU and doing a lot of > fs reads (slowing other opartions down) and performing writes that > negatively impact SSD wear. That's interesting. I've not played with that. The question is why Baloo sees the files as new files. * Do you see the snapshots "elsewhere" in the filesystem? * If you do a "stat one-of-your-files.txt", do you see the device number and inode of the file change (after the snapshot/reboot)? * If you do a "balooshow one-of-your-files.txt" do you see the DocID change? (the Id is built from the device number and inode. The way this is done has recently been changed to avoid reindexing, specifically in the BTRFS case) * If you do a "baloosearch -i one-of-your-files.txt" do you get a single result or many? The "DocId" is the 16 character hex string that comes first in the balooshow and at the beginning of the line in baloosearch.
Thanks for your comprehensive reply. > There has to be something else messing with it, this is not the usual behaviour... I'm stumped as to what is causing this TBH. > If it is disabled it generally stays disabled, and you can see the option in the > .config/baloofilerc When I execute `balooctl disable`, `~/.config/baloofilerc` is updated by adding the following to the top of the file: > [Basic Settings] > Indexing-Enabled=false Once I reboot, the above is once again deleted from the file and baloo_file keeps running. > Keep an eye on this, see if it is being changed back. You could try setting the config to "read only"... Making it read only once it is disabled works. Thanks! > * Do you see the snapshots "elsewhere" in the filesystem? Yes, these snapshots are elsewhere in the filesystem, but I specifically disabled `baloo` from indexing those locations a while back: ``` exclude folders[$e]=$HOME/.cache/,$HOME/.local/,/mnt/,/run/media/,/.snapshot/,/home/.snapshot;/config ``` > * If you do a "stat one-of-your-files.txt", do you see the device number and inode of the file change (after the snapshot/reboot)? No, the device number and inode remain unchanged. > * If you do a "balooshow one-of-your-files.txt" do you see the DocID change? (the Id is built from the device number and inode. The way this is done has recently been changed to avoid reindexing, specifically in the BTRFS case) No, the `DocID` stays the same. > * If you do a "baloosearch -i one-of-your-files.txt" do you get a single result or many? I get a single result.
(In reply to MarkW from comment #2) > > * Do you see the snapshots "elsewhere" in the filesystem? > > Yes, these snapshots are elsewhere in the filesystem, but I specifically > disabled `baloo` from indexing those locations a while back: > > exclude folders[$e]=$HOME/.cache/,$HOME/.local/,/mnt/,/run/media/,/.snapshot/,/home/.snapshot;/config I've just had a "doh!" moment. The paths for the snapshots is wrong in the exclude folders setting. They should be `.snapshots`, not `.snapshot`. I have corrected them and re-enabled baloo now to see whether its bad behaviour continues, or whether it will now settle down.
(In reply to MarkW from comment #2) > Thanks for your comprehensive reply. All part of the service! > Once I reboot, the above is once again deleted from the file and baloo_file > keeps running. I don't think it is Baloo thing in that case, something else in the startup or logon sequence is enabling it. I was wondering about the config being overwritten by the system default (hmm, that could be in "/etc/xdg/baloofilerc" or "/usr/share/kde-settings/kde-profile/default/xdg/baloofilerc"), but if your baloofilerc retains its exclusions, then probably not... (In reply to MarkW from comment #3) > ... I've just had a "doh!" moment. The paths for the snapshots is wrong in the > exclude folders setting. They should be `.snapshots`, not `.snapshot` ... Ahhh! I thought "doh!" moments were my thing 8-) I assume you have a structure of "copies" under the .snapshots folder and Baloo will be seeing these files "for the first time" although I'm not sure I understand the: >> If you do a "baloosearch -i one-of-your-files.txt" do you get a single result or many? > > I get a single result. My naive assumption (without having tried BTRFS snapshots) is that you'd also find the snapshot copies of your file.
>> Once I reboot, the above is once again deleted from the file and baloo_file >> keeps running. > I don't think it is Baloo thing in that case, something else in the startup or logon sequence is enabling it. It would be great to track that down. I've been trying to use `auditd` to do this by creating a custom watch rule in `/etc/audit/rules.d/baloorcwatch.rules`: ``` -w /home/mark/.config/baloofilerc -p wa ``` So far, it's a toss-up between `balooctl` and `systemsettings`. I haven't had the time to properly decode the auditd logs to see which one is the culprit at this stage. >I was wondering about the config being overwritten by the system default (hmm, that could be in "/etc/xdg/baloofilerc" or "/usr/share/kde-settings/kde-profile/default/xdg/baloofilerc"), but if your baloofilerc retains its exclusions, then probably not... Yes, the exclusions are retained, so something else is doing this. > Ahhh! I thought "doh!" moments were my thing 8-) You can't (unfortunately for me) claim a monopoly in that department :-) > I assume you have a structure of "copies" under the .snapshots folder and Baloo will be seeing these files "for the first time" although I'm not sure I understand the: >> If you do a "baloosearch -i one-of-your-files.txt" do you get a single result or many? >> I get a single result. >My naive assumption (without having tried BTRFS snapshots) is that you'd also find the snapshot copies of your file. Yes, that is odd. I can confirm that after correctly excluding the snapshots, baloo_file still consumes quite a bit of CPU when things get busy on the filesystem, but it is nowhere near as debilitating now that the snapshots are excluded from its ambit. I can now safely leave it enabled.
(In reply to MarkW from comment #5) > ... So far, it's a toss-up between `balooctl` and `systemsettings` Systemsettings reads baloofilerc and write back changes, as far as I can tell. The question is whether it has its own "state", where it thinks it should write back a change to baloofilerc but thinks it has not managed. Undiluted speculation of course. Maybe try moving your baloofilerc to somewhere safe and see if systemsettings sees your search configuration vanish...