GNOME Bugzilla – Bug 731739
Nautilus stuck / freezes when searching on slower media or if disk under high load
Last modified: 2021-06-18 15:30:15 UTC
Created attachment 278553 [details] backtraces of nautilus Nautilus stuck when I try search if disk under high load Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQMHU1cHFFZmVCOWc/edit?usp=sharing
Created attachment 285565 [details] screencast I have the same problem, except that my machines are under no load at all. On my desktop with a conventional hard drive, whenever I start typing something to search, no matter which folder I'm in (doesn't even need to be ~/Documents or ~), Nautilus freezes up completely. Maybe in a few minutes i'll see it unfreeze and show search results. This issue does not occur on my laptop which has the same stack (GNOME 3.12 on Fedora 20) but a Solid State drive instead of a conventional HDD. I always end up using "locate -i", which is pretty sad. Nautilus should not ever block on something meant to be async like search, and it should provide some sort of "please wait" indication and allow cancelling the search.
Not sure if dupe of bug #732347 Bug #709107 is about remote media
Just a quick technical sanity check: in nautilus-query-editor.c, in the "entry_changed_cb" callback function, there is a 250 miliseconds typing timer, so at least it's not that the search backend is being "spammed" with every keystroke when typing rapidly. I see that this issue occurs in my ~/Documents folder with the conventional hard disk drive (that folder has 26 033 items, totalling 17.8 GB), however it does not happen if you're into a small subfolder with not too many items.
Hi Jean-Francois, thanks for the video. It looks like Tracker is still indexing. I've been toying with an idea to allow users to completely disable indexing when the user is using the system, i.e. only when the keyboard/mouse has been idle for some minutes to start up again... What version of Tracker are you using? It totally looks like your disk is just being hammered at the time. Since Tracker has to read from the disk it's also thrashing, that's likely the problem. Nautilus itself shouldn't be the issue and all queries are done async to Tracker.
(In reply to comment #4) > What version of Tracker are you using? $ rpm -q tracker tracker-1.2.2-2.fc21.x86_64
Hmm, I tried to look into this tomorrow, but I actually couldn't tell if Tracker was being used at all by Nautilus. My jhbuild set up didn't seem to be. Will try again today...
For me it's tracker-1.0.2-1.fc20.x86_64, but thankfully Mikhail is experiencing it with a newer version.
Just to let you know, I've been playing with the Nautilus Tracker plugin, which is maintained by Nautilus and it's not in the Tracker tree. It's quite easy to trigger a condition where the search gets stuck and I don't think it's a load related problem. I've got a local branch I'm working on and I will push it for review later. Some of the updates include: - Allowing connections to be obtained if they previously failed - Getting the Tracker connection asynchronously not sync - Only searching when we have finished typing - Don't try to search for anything less than 3 characters - this is often pointless. There may be some other updates too.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.