| Summary: | baloo_file crashes when run | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | Valtti Rinnemaa <valttirinnemaa> |
| Component: | Baloo File Daemon | Assignee: | baloo-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | tagwerk19 |
| Priority: | NOR | ||
| Version First Reported In: | 5.94.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Valtti Rinnemaa
2022-06-12 10:45:42 UTC
I deleted baloo db manually (just removed the whole ~/.local/share/baloo folder) and then did a new first run and now it works properly. Somewhere along the line, someone would have recommended deleting the index and starting again from scratch. Quite often by saying to try "balooctl purge"
There *are* still instances of MDB_BAD_TXN reported but thankfully far, far fewer than a couple of years back. It's a report from LMDB library and suggests a corruption of the index. The "markFailed" seen in the dump should generate a "Not able to commit to DB, DB likely is in a bad state. Exiting" failure - but the process crashes first.
You are on Arch, do you have it set up using BTRFS?
If so, there's a test you can do that might give a hint (baloo can struggle with BTRFS and multiple subvols), see:
https://bugs.kde.org/show_bug.cgi?id=402154#c12
If you are running into this, baloo will be reindexing your files after each reboot (not fully reindexing every time, but will be thinking it has 8 to 10 different discs that appear and disappear again and it needs to do a lot of "catching up"). This can make the index, and memory usage, pretty large...
Thanks for the thorough explanation and info! I'm using ext4 as a filesystem. BTW: I was working on a personal project and did a git reset --hard and changed the directory and file structure just before the bug started occuring if my memory serves me right. "kf.baloo: "/home/ *snip (it was the same file)* " id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created" ^^^ and this was one of the project files. It might have already been broken though since it insinuates that baloo might not have been running while the file was deleted + re-created. Now I don't know if this has anything to do with the corruption of the index (I also installed and then removed some packages during the same session) but these are just some things I remember doing before it started crashing on startup. (In reply to Valtti Rinnemaa from comment #3) > BTW: I was working on a personal project and did a git reset --hard and > changed the directory and file structure just before the bug started > occuring if my memory serves me right. Baloo should be able to cope if a file is deleted and another "appear" with the same inode. Normally it would be told of changes via iNotify but if it misses the notification, it would normally catch up after a relogon or "balooctl check". However it can get a bit stressed with "large scale" deletions. It can be that deletions "overflow" the iNotify queue - that is more than "sysctl fs.inotify.max_queued_events" happen. Also if there are a *load* of deletions these can take a while to process. I met this with Bug 437754. Your "git reset" might have been a bit hard on Baloo :-/ > However it can get a bit stressed with "large scale" deletions. It can be
> that deletions "overflow" the iNotify queue - that is more than "sysctl
> fs.inotify.max_queued_events" happen. Also if there are a *load* of
> deletions these can take a while to process. I met this with Bug 437754.
>
> Your "git reset" might have been a bit hard on Baloo :-/
Well it was just a few small text files so it doesn't sound likely. I also haven't done any "large scale" deletions or loads of deletions recently. I can't really think of anything out of the ordinary I would have done on my system that would have caused the corruption. It has been working fine now though.
(In reply to Valtti Rinnemaa from comment #5) > ... it was just a few small text files so it doesn't sound likely ... Ok, I'll admit that was a bit of guesswork. If you are back working, is it OK to close the bug report? (In reply to tagwerk19 from comment #6) > If you are back working, is it OK to close the bug report? Yes it's fine by me! (In reply to Valtti Rinnemaa from comment #7) > (In reply to tagwerk19 from comment #6) > > If you are back working, is it OK to close the bug report? > > Yes it's fine by me! Closing... |