| Summary: | baloo_file take 100% CPU | ||
|---|---|---|---|
| Product: | [Unmaintained] Baloo | Reporter: | Olivier Churlaud <olivier> |
| Component: | Baloo File Daemon | Assignee: | Vishesh Handa <me> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | critical | CC: | j, rosspoko |
| Priority: | NOR | ||
| Version First Reported In: | 5.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Olivier Churlaud
2015-02-11 14:41:36 UTC
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. |