UPDATE: I just noticed the not responding prompt on a nightly build of Files as well when tracker3.Miner.Files starts happening, but the difference is that it managed to recover on its own unlike the rev. bundled with F37
I have a very similar set of possibly Tracker related bugs:
nautilus doesn’t open or the moment I search a file it hangs forever
search in GNOME activity stops providing results for files after around 15s after user login
shutdown process is blocked for 1m30s by trying to stop tracker-extract-3 and/or tracker-miners-fs-3
I was unaware of this forum post. Thanks to IRC and Telegram friends I was able to determine it probably was, at least for me, a bug related to Tracker:
running
tracker3 reset --filesystem
Solved temporarily the issues 1 and 2, but shutdown still waits for a minute and a half. At next boot, the problems are still there.
When the above bugs occur
tracker3 status
never provides results.
I filed a bug report yesterday, feel free to add information.
You should be able to run nautilus from shell by issuing “nautilus” plus a folder location. For example,
nautilus .
opens the folder you are currently in the terminal. If nautilus is freezed, however, this should not respond. I fixed it by first killing nautilus with
It seems that me running killall nautilus has made it so I can reopen it from the GNOME menu consistently now. If it starts acting up again, I’ll try the tracker3 command.
Same issue here, just upgraded to Fedora 37 today.
Kernel: 6.0.8-300.fc37.x86_64
I have some NFS network mounting points configured in /etc/fstab using x-systemd.automount:
First attempt to launch nautilus from the teminal gave me this before crashing:
❯ G_MESSAGES_DEBUG=all nautilus
(org.gnome.Nautilus:9265): GLib-GIO-DEBUG: 13:29:19.805: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
(org.gnome.Nautilus:9265): GLib-GIO-DEBUG: 13:29:19.807: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ?gio-vfs?
(org.gnome.Nautilus:9265): Tracker-DEBUG: 13:29:19.810: Loading ontologies from database.
(org.gnome.Nautilus:9265): Tracker-DEBUG: 13:29:19.811: Applying ontologies from /usr/share/nautilus/ontology to existing database
(org.gnome.Nautilus:9265): Tracker-DEBUG: 13:29:19.811: Current and DB locales match: 'C'
** (org.gnome.Nautilus:9265): DEBUG: 13:29:19.812: *** Cancel Results Meta requests
Failed to register: Timeout was reached
Then I deleted ~/.cache/tracker3 and try again, nautilus would hang indefinitely, at a different step:
Hello @sgob, I tried to run tracker3 reset --filesystem but this did not help. Not even temporarily. I have submitted my previous post on the bug track, as per your recommendation.
I come up with a (possible) solution or workaround.
Today I launched a sway session, and in there tracker3 was working very well with nautilus.
Issuing command tracker3 status in the sway session, unexpectedly, instead of freezing it reported that there were some files that caused errors. In particular, they were some .png files and some .cue files. Removing them from my disk has solved the issue: now nautilus works as expected and also the activity bug disappeared and the shutdown is regular as usual.
I currently have no time to reproduce it: tomorrow I will try to load those files again in my disk, and try to reproduce the bug, and report both files and behavior in the bug report.
I solved it by issuing tracker3 status on Sway, but it could also work on a TTY you open before logging in into GNOME. Still, I am not sure whether you will be able to solve it like I did, or in a TTY, because I could just have been lucky.
Under Gnome Wayland, the command tracker3 status works normally, and lists some errors, all image files (jpeg and png). The error states “Could not get any metadata for uri:…”. The images appear to be corrupted, I cannot open them from the terminal (using display). After I remove the images, tracker3 returns no error:
❯ tracker3 status
Currently indexed: 9551 files, 348 folders
Remaining space on database partition: 336.6 GB (33.71%)
All data miners are idle, indexing complete
I finally got nautilus working !
I found this post on reddit suggesting to remove nautilus-python. I did, using sudo dnf remove nautilus-python and after a reboot nautilus stared to work again normally.
I have the same issue with nautilus: sometimes it doesn’t even launch, and sometimes it freezes/crashes after some time This is really annoying. Is this issue already reported? (I’ve just upgraded from 36 to 37)
Yes, this has already been reported here. Since I started the bug report, some people added their feedback plus additional details. You are invited to do so, if you wish.
uname -a
Linux ux501v 6.0.17-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jan 4 15:58:35 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
nautilus --version
GNOME nautilus 43.1
if I kill the tracker-miner-fs3 process all works faultless ( probably not the indexes )
as long as I keep this process nautilus just timeout and don’t start