https://bugs.kde.org/show_bug.cgi?id=384372
--- Comment #8 from Heinrich Seebauer <heinrich.seeba...@swistec.de> --- (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 -- You are receiving this mail because: You are watching all bug changes.
