| Summary: | baloo_file crash preventing system from sleeping or going into hibernate | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | Randall Larson <kde> |
| Component: | Baloo File Daemon | Assignee: | baloo-bugs-null |
| Status: | REPORTED --- | ||
| Severity: | crash | CC: | tagwerk19 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Randall Larson
2024-09-23 05:00:25 UTC
Disabling baloo and rebooting seems to be the workaround as I am now able to sleep and hibernate and recover my system without rebooting. I did find https://discuss.kde.org/t/baloo-file-extractor-constantly-crashes/18616 which looks partially related, though the crash only happens for me when I sleep or hibernate. (In reply to Randall Larson from comment #1) > Disabling baloo and rebooting seems to be the workaround as I am now able to > sleep and hibernate and recover my system without rebooting. I did find > https://discuss.kde.org/t/baloo-file-extractor-constantly-crashes/18616 > which looks partially related, though the crash only happens for me when I > sleep or hibernate. That ought to be "history" now... It is interesting that it is "baloo_file" crashing and not "baloo_file_extractor", the latter does the heavy lifting of getting the plain text out of the various format files. That is more often the source of trouble. I have two guesses... Baloo's index has got just plain "too large". I might say that's reasonably likely as you are running on BTRFS. Check how big your ~/.local/share/baloo/index file is.... Second option is that Baloo is swapping. That's not something that you want... The actual impact on the system depends on whether Baloo is running under systemd or not - there is a kde-baloo unit file that sets a limit on memory usage. (In reply to tagwerk19 from comment #2) > Baloo's index has got just plain "too large". I might say that's reasonably likely as you are running on BTRFS. Check how big your > ~/.local/share/baloo/index file is.... (Sorry new to Bugzilla so not sure if I can use markdown formatting) $ ls -lh .local/share/baloo/index -rw-r--r-- 1 <USER> <GROUP> 2.6M Sep 22 22:45 .local/share/baloo/index I am using btrfs, but the index file does not seem _that_ big, but I am also not familiar with the inner workings of Baloo. I've noticed this crash happens when its in the process of attempting to index files on my fusemount (rclone to MS OneDrive). Right now, it does seem to be "hung" when trying to index a photo of type .heic. For the short term, I will disable indexing of my fusemount, but is it _expected_ that it hang on .heic files? (In reply to Randall Larson from comment #3) Excluding .heic allowed indexing to not become hung on those file types, but hibernate/sleep is still problematic when indexing my fuse mount. I suspect there may be two bugs happening here, though the latter is more disruptive for a laptop. (In reply to Randall Larson from comment #3) > $ ls -lh .local/share/baloo/index > -rw-r--r-- 1 <USER> <GROUP> 2.6M Sep 22 22:45 .local/share/baloo/index > > I am using btrfs, but the index file does not seem _that_ big .... No, that's not big. You should start worrying when it gets as big as your available RAM (as a very, very approximate measure) > ... I've noticed this crash > happens when its in the process of attempting to index files on my fusemount > (rclone to MS OneDrive). Right now, it does seem to be "hung" when trying > to index a photo of type .heic. For the short term, I will disable indexing > of my fusemount, but is it _expected_ that it hang on .heic files? Well, you can try copying the .heic to a non-fusemounted folder or you can get a test sample. I tend to go to https://filesamples.com/ You can try doing the indexing in the foreground, with: $ balooctl index sample1.heic and check what's been extracted with $ balooshow -x sample1.heic (Possibly with balooctl6 and balooshow6 rather than balooctl and balooshow) I'm still a little suspicious that it is baloo_file failing and not baloo_file_extractor. If there was an issue reading or extracting the metadata, it would be the extractor crashing... |