GNOME Bugzilla – Bug 705958
Tracker unresponsive and unstable; D-Bus or Filesystem miner to blame?
Last modified: 2014-11-30 03:14:59 UTC
Tracker seems to hang on me all the time. If I start it with my system login, I’ll get critical error messages such as: - “Tracker-CRITICAL **: Cannot create a proxy on the D-Bus session bus, Error calling StartServiceByName for org.freedestop.Tracker1.Miner.Files: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/lib/tracker/tracker-miner-fs received signal 6” - “Tracker-CRITICAL **: Cannot create a proxy on the D-Bus session bus, Error calling StartServiceByName for org.freedestop.Tracker1.Miner.Applications: Timeout was reached” - “Tracker-CRITICAL **: Could not get miner progress for 'org.freedesktop.Tracker1.Miner.Files': Timeout was reached” - “Tracker-CRITICAL **: Could not get miner progress for 'org.freedesktop.Tracker1.Miner.Applications': Timeout was reached” Sometimes when I start it manually from a shell it’ll work, but roughly half the time I get the D-Bus connection timeout errors above. Checking the status with `tracker-control -S` or `tracker-control -F` again often reports a timeout. Added to all this, when it does start up, I’ll get prolonged periods of high CPU load. Before I typed this bug report, I checked the status and the filesystem miner reported an approximate time of 1768 days (!). I’ve tried setting the log level to debug, but nothing is written to the logs in ~/.local/share/tracker/ (if that’s where they are stored). ----------------------------- SYSTEM INFORMATION ----------------------------- Distribution: Arch Linux x86_64 Kernel version: 3.10.5 Tracker version: 16.2 (built on 2013-08-02 according to my package manager) Desktop environment: nil — most user services are controlled by a `systemd --user` instance. Window manager: Openbox
Please see https://wiki.gnome.org/Tracker/Documentation/Debugging
Thanks André for pushing the debug details. Zogaeski, getting these errors is pretty critical. The first error is a failure returned from DBus itself and one of the first things we do. 9 times out of 10, this error is down to a badly configured environment or DBus set up. DBus needs to spawn the processes for us and it is failing at that. Sometimes, it's related to miner-fs failing for some simple reason when DBus tries to spawn it (e.g. no disk space, or corrupt DB). It would be good to see logs for running: $ export TRACKER_VERBOSITY=3 $ /usr/libexec/tracker-miner-fs Just to see if there are any errors being reported. If it aborts early on then that would also explain why we get those criticals.
Ok, so I enabled logging and set a higher verbosity, and here’s the output of a run on a fresh boot (so straight after booting and logging in). I started it manually (the service was disabled) and it seems to hang whilst waiting for a connection: $ export TRACKER_VERBOSITY=3 $ /usr/lib/tracker/tracker-miner-fs Tracker-Message: Importing config file to GSettings Tracker-Message: Starting tracker-miner-fs 0.16.2 Tracker-Message: Using log file:'/home/robbie/.local/share/tracker/tracker-miner-fs.log' Tracker-Message: General options: Tracker-Message: Verbosity ............................ 3 Tracker-Message: Sched Idle ........................... 2 Tracker-Message: Initial Sleep ........................ 15 Tracker-Message: Indexer options: Tracker-Message: Throttle level ....................... 0 Tracker-Message: Indexing while on battery ............ yes (first time only = yes) Tracker-Message: Low disk space limit ................. 1% Tracker-Message: Setting priority nice level to 19 Tracker-Message: Checking if we're running as a daemon: Tracker-Message: Yes (tracker-miner-fs:1906): Tracker-DEBUG: tracker-backend.vala:33: Waiting for service to become available... It sat there apparently not doing anything, so in a different terminal I ran: $ tracker-control -S Store: (tracker-control:2115): Tracker-CRITICAL **: Could not retrieve tracker-store status: Timeout was reached Miners: 15 Aug 2013, 11:27:18: ✗ File System - Not running or is a disabled plugin 15 Aug 2013, 11:27:18: ✗ Applications - Not running or is a disabled plugin I’ve attached the the log file from this morning’s run, though I trimmed out repeated runs of “Adding monitor for PATH” lines.
I kept getting a TLS timeout error when I went to add the attachment so here’s the log: https://gist.github.com/zoqaeski/6237594
(In reply to comment #5) > I kept getting a TLS timeout error when I went to add the attachment so here’s > the log: > > https://gist.github.com/zoqaeski/6237594 Other than exceeding the maximum number if inotify watches, I don't see a problem running the tracker-miner-fs. I certainly don't see the critical warnings you mentioned above. Did you build/install tracker yourself or use a packaged version ? Can you try running the store in the same way you do tracker-miner-fs to make sure it's OK and pastebin the output of that? Short of that, a reindex might be worth a try, but it shouldn't be necessary. When was the last time you created your index from scratch?
(In reply to comment #6) > (In reply to comment #5) > > I kept getting a TLS timeout error when I went to add the attachment so here’s > > the log: > > > > https://gist.github.com/zoqaeski/6237594 > > Other than exceeding the maximum number if inotify watches, I don't see a > problem running the tracker-miner-fs. I certainly don't see the critical > warnings you mentioned above. > > Did you build/install tracker yourself or use a packaged version ? > > > Can you try running the store in the same way you do tracker-miner-fs to make > sure it's OK and pastebin the output of that? > > > Short of that, a reindex might be worth a try, but it shouldn't be necessary. > When was the last time you created your index from scratch? Hi Robbie, I am closing this bug report as no updated information has been provided. Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.
I was running tracker in a mishmash desktop comprised of many (probably incompatible) parts, including Xfce, GNOME and Openbox, so chances are something wasn't being done right somewhere in the session initialisation. I've since switched to GNOME 3.14 (after spending a few months on Cinnamon) and I haven't had those errors occur, though I do seem to get not-infrequent segfaults and coredumps that seem to be triggered by one or two files I have. I'll post a separate bug report for that though.