Well i cannot say much more since I don't know how to debug baloo. Here what package I have installed extra/baloo-frameworks 5.6.0-1 [installed] extra/baloo4 4.14.3-1 <====Not installed extra/baloo4-akonadi 4.14.3-1 [installed] extra/baloo4-widgets 4.14.3-1 [installed] extra/libbaloo4 4.14.3-1 [installed] Reproducible: Sometimes
Just adding this snippet of information if it helps. I noticed my computer acting up and found baloo_file_extractor taking up 100% CPU. Note: I've had it disabled for a long time and it enabled itself in a recent update (even tho the checkbox "Enable Desktop Search" is still not checked). I've since disabled it again with: balooctl disable Same versions installed as poster, except I don't have baloo4-akonadi.
Was it the baloo_file or baloo_file_extractor process?
I tell you this next time it happens
This is happening for me as well. It is the baloo_file process. Once the problem is triggered, It takes up a consistent 100% CPU (1 core). Using iotop, I do not see it performing any file IO, and using strace, I do not see it making any system calls at all while the issue is occurring. I have generally noticed that the issue appears to be triggered for me after I run `npm install` on one of my development projects, which copies a moderate number of files from one directory to another. Strangely, this project is in a folder which baloo is supposedly configured not to index, judging from the Desktop Search module in System Settings. However, running this command does also result in files being written in ~/.npm and /tmp, so perhaps it is one of those locations that is triggering the problem.
It seems like the xapian database is getting corrupted for a few users. We're in touch with upstream (xapian) and we're trying to figure out a way to fix this. Till then, the best way is to just reset the indexing - $ balooctl disable $ balooctl enable *** This bug has been marked as a duplicate of bug 341581 ***
When I run $ balooctl disable The stuck process does not die or change behavior. I still have to kill it with SIGTERM
(In reply to Ross Pokorny from comment #6) > When I run > $ balooctl disable > The stuck process does not die or change behavior. I still have to kill it > with SIGTERM Yeah. Could be. Kill it, disable it, and then enable.