Everyone on the internet seems to be full of good ideas about how to turn tracker off. I am rather fond of it, but on my main computer, a Ubuntu 20.04 box, it has started failing and despite purge and reinstall of the package I have not been able to revive its function. Especially the text indexing which I find so useful. Is there any step-by-step guidance short of ‘reinstall your OS’, to find the cause of this?
It would be good if the tracker binary itself had a bit more of a diagnostic bend, too.
me@me-somebox:~$ tracker daemon start
Store:
21 Oct 2021, 21:44:17: ✗ Store - Unavailable
Miners:
21 Oct 2021, 21:44:17: ✗ Extractor - Not running or is a disabled plugin
21 Oct 2021, 21:44:17: ✓ File System - Idle
It would be good if the tracker binary itself had a bit more of a diagnostic bend, too.
FTR, we thought the exact same. In the 3.x series there’s been substantial improvements to diagnosing indexing failures from the command line.
Unfortunately, AFAIU Ubuntu still stays in the now old 2.x. It is unfortunate that it has become a late adopter. Tracker is now heading towards the 3.3.x. series (current stable is 3.2.x), the upstream Tracker team has limited capacity and does not support 2.x anymore.
it has started failing and despite purge and reinstall of the package I have not been able to revive its function. Especially the text indexing which I find so useful.
This is unfortunate, as it seems from your output, tracker-extract is failing to start, this process is the one extracting metadata from your files. Since this depends on a number of libraries to do the task, there 2 reasons why it might have started failing:
A library update introduced new syscalls being done at runtime that are forbidden for that process. There’s e.g. been some noise lately with clone3.
A library update introduced crashes where it previously did not.
Since that process uses seccomp to limit the amount of things metadata extractors can do, a forbidden syscall is the most likely to happen if the rest of the software stack got updates with a stale tracker-miners. Either way probably Ubuntu should be contacted about this, I think any fix/backport will be better done on their side.
Running the tracker-extract executable manually might help figure things out, e.g.:
$ /usr/lib/tracker/tracker-extract
That should hint which of those is, and coredumpctl could be used to get further information from there.
The packages seem to be there. I see a version inconsistency between focal/updates (2.3.6) and focal (2.3.3) and wonder if this could have something do to with it.
That means there are no extraction failures and no files left to get metadata extracted. This daemon is able to shut down in inactivity situations to free up memory, and will be started later on as necessary.
Let’s take a step back, how did you determine the tracker daemon --start output is related to you not being able to search?
How do you regularly search files? Did you try with the tracker search command?
Happy to help . I’m also unclear how it broke and fixed itself, perhaps it was a one-off situation that Nautilus failed to connect to the Tracker daemon.
If you can pinpoint it to Nautilus in the future that should be definitely moved forward in Ubuntu bug reporting system, AFAIU Nautilus is patched there to revert the upstream port to Tracker 3.x.
I just wish I knew what caused it when it was not working. I do not like mystery behaviour. 
. I’m also unclear how it broke and fixed itself, perhaps it was a one-off situation that Nautilus failed to connect to the Tracker daemon.