5

I'm managing a fleet of 25 Ubuntu 22.04 systems. On one of them (possibly more I haven't discovered yet), tracker-miner-fs keeps crashing, and I can't figure out how to get control of that.

I have Ubuntu 22.04 with all the latest updates installed. Tracker is version 3.3.0-1

I only have command-line access to these systems by SSH, since the actual systems are 60 miles away. Access to the physical console is not a practical option.

I find these kinds of entries in /var/log/syslog:

Nov 17 09:32:24 bec315dl06 tracker-miner-f[6049]: SQLite error: database disk image is malformed (errno: Success)
Nov 17 09:32:24 bec315dl06 tracker-miner-f[6049]: message repeated 131 times: [ SQLite error: database disk image is malformed (errno: Success)]

The general recommendation for this problem is "tracker3 reset -s". However, that errors out:

~# tracker3 reset -s

(tracker reset:6269): GLib-GIO-CRITICAL **: 10:03:26.952: g_dbus_connection_send_message_with_reply_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(tracker reset:6269): GLib-GIO-CRITICAL **: 10:03:26.952: g_dbus_connection_send_message_with_reply_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(tracker reset:6269): GLib-GObject-CRITICAL **: 10:03:26.952: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Found 0 PIDs…

tracker3 status also errors out:

~# tracker3 status
Could not establish a connection to Tracker: Cannot autolaunch D-Bus without X11 $DISPLAY

That is not completely surprising, since I'm using an SSH connection.

At this point, I'm lost. I am not very familiar with the intricacies of D-Bus.

Is there a way to reset tracker manually, and would that fix all the problems, or would it just bypass some D-Bus issues that should also be resolved?

2 Answers2

4

You should do two things:

1 - Reset the filesystem database

tracker3 reset --filesystem
Found 1 PID…
  Killed process 22557 — “tracker-miner-fs-3”

2 - Restart the Tracker daemon to ensure that it starts reindexing your files from a fresh state

tracker3 daemon --kill
tracker3 daemon --start
Peter_duke
  • 41
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Community Jul 18 '24 at 13:22
  • As an additional data point: I also ran into the analogous issue on RedHat 8. tracker reset did not fix the issue, but downgrading the tracker RPM, and then upgrading it again seems to have helped. – Kevin Keane Jul 19 '24 at 16:09
2

I found a partial answer.

Since tracker3 reset -s is not working, the way to repair the tracker database is as follows:

  • kill the tracker-miner-fs-3 process.
  • delete the SQLite database in /var/lib/gdm/.cache/tracker3
  • Reboot the system.
  • Confirm in /var/log/syslog that tracker3 no longer reports SQLite errors (there may be messages regarding a missing file).

There are additional tracker databases for each user in $HOME/.cache/tracker3 . In my case, the home directories are on an NFS share, which of course increases the risk of corruption.

The problems with tracker3 reset -s and tracker3 status still exist.

  • Whoever downvoted this - would you provide a better answer, or at least explain why you downvoted this? – Kevin Keane Nov 20 '23 at 06:06
  • 1
    I upvoted your question and answer because sometimes they give you a downvote and do not explain why ... – R13mus Dec 13 '23 at 08:28