What "package" keeps re-installing tracker-miner ?

English Applications
1

I’ve uninstalled all the related tracker-miner packages on at least 4 occasions since I installed TW on this laptop.

Yet every now and again, it slows to a crawl, and I look at what is running and tracker-miner is using 100% cpu at boot up and making my laptop unusable (or extremely laggy / IO / CPU bound)

Since I have uninstalled tracker-miner, I must obviously have a package installed that doens’t complain when you remove tracker-miner, but does (automatically) pull it in when that package gets updated via a zypper dup

I note that when I did a zypper info tracker-miner it did say that it had been installed “automatically”

I can see there are two (or 3) ways to fix this.

A) leave config that means that if tracker-miner i ever reinstalled, it doesn’t run

B) stop tracker-miner from ever getting reinstalled automatically when I have explicitly removed it

Option C) would be to have tracker-miner running but it would not make my computer unusable whilst it does so.

Can anyone give me the answers to this?

I note that removing all the tracker related package also removed Nautilus?

Is Nautilus the package that drags in tracker-miner?

Or is there a way in zypper to blacklist packages that you have manually uninstalled? So that even if a package tries to drag in tracker-miner as a dependency, it won’t do so?

PS, please give your experience with tracker-miner

i have a 2TB 2.5in SATA drive in a reasonably specced laptop, and it becomes unusable after a reboot when tracker-miner has been re-installed

This may be different if you have a 128Gb SSD

2

BTW

I know thee are / were files in

/etc/xdg/autostart

to do with tracker-miner

I modified all of them to change (and i forget the exact phrase)s tart at boot from “true” to “false” -

and they were still running and eating my cpu after a reboot…

3

Yes. The easiest way is to use Yast Software Management, right click on the package and mark it to never be installed. But you can also use “zypper al” to add a lock.

So that even if a package tries to drag in tracker-miner as a dependency, it won’t do so?

It doesn’t quite work that way. If there’s a dependency, you will get a conflict resolution dialog. However, if the package is being pulled in by a recommend (instead of a dependency), then the lock completely takes of that.

PS, please give your experience with tracker-miner

I disable it where I can. I normally use KDE, and it is not starting there or in XFCE. But I think it starts when I login to Gnome, though I have not checked carefully.

4

I logged into XFCE, and configured the tracker programs to not autostart.

That left some files in “.config/autostart/”
For example here’s one (a 3-line file):


  ---- .config/autostart/tracker-miner-fs.desktop ---
[Desktop Entry]
Hidden=true

Yes, that last is a blank (or empty) line. My understanding is that “.desktop” file in “.config/autostart” overrides the default “.desktop” file of the same name, and the “Hidden” attribute causes it to then be ignored. But I’m not an expert on how those files are used.

5

There is no package “tracer-miner”. There is “tracker-miners” or various 'tracker-miner-*" packages. Removing tracker-miners does not force removal of nautilus here.

6

OK, thanks for the answers

I was being a bit imprecise about the various tracker-miners packages and was trying to use tracker-miner as a generic catchall for all of them

So packages I did remove were

tracker-miner-files
tracker-miners
tracker-miners-lang
libtracker-miner-2_0-0
tracker-lang tracker
libtracker-sparql-2_0-0
libtracker-control-2_0-0
libtracker-common-2_0
grilo-plugin-tracker

I believe that removing that last one was the one that also removed Nautilus

I note that if I do a

sudo zypper in nautilus

then zypper also tries to install some “tracker” packages as well.

The following 13 NEW packages are going to be installed:
  gnome-shell-search-provider-nautilus grilo-plugin-tracker libtracker-common-2_0 libtracker-control-2_0-0 libtracker-miner-2_0-0 libtracker-sparql-2_0-0 nautilus nautilus-lang
  tracker tracker-lang tracker-miner-files tracker-miners tracker-miners-lang

The following 4 recommended packages were automatically selected:
  nautilus-lang tracker-lang tracker-miner-files tracker-miners-lang

So it looks as though the parent package for “tracker” is possibly nautilus ? Or maybe even just gnome-shell?

Brasero also tries to bring in all those tracker packages as well

sudo zypper in brasero

The following 13 NEW packages are going to be installed:
  brasero brasero-lang grilo-plugin-tracker libtracker-common-2_0 libtracker-control-2_0-0 libtracker-miner-2_0-0 libtracker-sparql-2_0-0 totem-plugin-brasero tracker tracker-lang
  tracker-miner-files tracker-miners tracker-miners-lang

The following 4 recommended packages were automatically selected:
  brasero-lang tracker-lang tracker-miner-files tracker-miners-lang

So I will try blocking the package “tracker” as a first attempt, as nrickert described.

Thanks for that, and apologies for being somewhat imprecise in the OP.

7

Assuming that, you’ve still have the package (or packages) installed which require the “tracker-miners” package, use rpm to perform the following query:

rpm --query --whatrequires tracker-miners

You may also need to perform the following housekeeping:


rpm --rebuilddb
zypper verify
rpm --verify --all

Please note that, the “rpm --verify” is fairly verbose and, you’ll more than likely need to either pipe the output through “less” (or “more)” or, redirect the output to a file …

8

Tracker-miners is a Gnome file indexing app.
Improperly configured file indexing apps have been a common cause of User complaints over the years, typically “Eating 100% CPU”

I do not recommend removing the files,
Instead I recommend modifying the “Niceness” of the file indexing process.
I haven’t recently done this, but noted awhile back to myself that systemd now has a different way of setting the “Niceness” value, so should be looked up.
This shouldn’t be particularly difficult to do and should be within the capabilities of many Users with a little research.
If you run into problems looking up the systemd way of configuring the Nice value, post here and you’ll get some help.

Hers is some Project info on trackers-mining which now should only have background value since the proper solution doesn’t require any direct knowledge of the app

https://github.com/GNOME/tracker-miners
https://wiki.gnome.org/Projects/Tracker

After you find settings you’re happy with,
I’d expect that others will appreciate it if you submit your findings to https://bugzilla.opensuse.org, so that your settings might be submitted upstream.

TSU

9

That’s a terrible crutch for letting a run-away process burn in the background.

10

I don’t know why so many people find it difficult to disable indexing software in KDE and GNOME and making it difficult by uninstalling things and editing scripts and what not.
While just like baloo in KDE, you can in GNOME turn tracker of with just a few mouse clicks:

https://paste.opensuse.org/view/raw/55194458
Operius.

11

Not a terrible crutch,
I’d consider modifying the process priority (aka Nice) as the optimal solution…
File indexing can be a great benefit for looking up files on a machine with many, many files, particularly when you use advanced search parameters… If you disable search indexing then it can take much, much longer (maybe >30 min vs under a minute?) for large, complex searches without using indexing. You can also look at this feature as an adaptation of what is commonly found in RDBMS (like MySQL) to perform fast, efficient lookups in very large datasets.

And, because indexing involves heavy disk I/O which is a common system bottleneck, the system load is impacted greatly.

When you configure the niceness of a process to run with a low priority,
You have the best of all worlds…
You have the benefit of fast file lookups.
The file indexing (which may run at least once a day on Desktops) updates unnoticed, only using normally idle resources in between User activity.

IMO switching off file indexing should remain an option, but for off/on to be the only options is lazy/expedient coding reacting to poor behavior when a “best of all worlds” solution exists.

TSU