16

Disabling the resource-hogging, data-copying Gnome tracker daemons is much harder than it ought to be. I'm running a recent installation of (stable) Debian 11.2 with Gnome.

One suggestion I found was to edit all /etc/xdg/autostart/tracker-*.desktop files such that

X-GNOME-Autostart-enabled=false (it was true)

Although this allegedly worked for somebody, once upon a time, alas, this change had no discernible effect.

Since I'm running version 2 of the tracker stuff I also tried:

systemctl --user mask tracker-store.service tracker-miner-fs.service tracker-miner-rss.service tracker-extract.service tracker-miner-apps.service tracker-writeback.service

That worked, evidently, although the system log still constantly reports that tracker services are "successful". Maybe those entries are artifacts of how systemd is being configured for tracker services. The problem with that "masking" method turned out to be that the reverse operation (mask -> unmask), to re-enable tracker daemons did not work for me. (Yes, I rebooted, as instructed. Nevertheless, the tracker daemons didn't return to operation.)

Steve Newcomb
  • 371
  • 1
  • 3
  • 6
  • Why do you want to disable those daemons? As far as I gather from the package descriptions they don't track the user, and can't do much unless configured to. But if you really want to, nothing stops you from removing the packages, There is some kind of dependencies from some meta-packages (e.g. gnome) but those just exist to pull in a lot of stuff, the system doesn't stop working if you remove them. – Henrik supports the community Mar 12 '22 at 08:43
  • 2
    The daemons use system resources that I don't want used for that purpose, obviously. Moreover, they copy data and/or make records of the existence of data. And, contrary to what you say, the packages themselves cannot be removed without disabling Gnome. Just try installing or updating Gnome while prohibiting the tracker packages. It won't work. If, as you say, "[Gnome's tracker package dependencies] just exist to pull in a lot of stuff", why is it impossible to install Gnome without them? And here's my own question: why isn't there a switch for tracker? – Steve Newcomb Mar 13 '22 at 12:25
  • I only use Gnome under my Kodi (it's probably a waste of resources, but I seldom see that Gnome so I haven't bothered to change it. But I just rebooted that machine after having removed those packages, and Gnome started as normally. There weren't any Gnome packages among those available for upgrade, so I'll claim that I have successfully removed those packages. – Henrik supports the community Mar 14 '22 at 20:10
  • Removing the tracker packages after installation may work. In my experience, installing Gnome while prohibiting the same packages via apt does not work. I wonder whether this is really a Gnome branding issue. Or perhaps some kind of installation-initialization issue. Anyway, somebody somewhere decided that if you install Gnome on Debian 11, you are going to install tracker, and that's that. – Steve Newcomb Mar 15 '22 at 15:55
  • 1
    I learn a lot by watching the system log. It turns out that tracker is started for a user that does nothing but cron jobs, never logs in, and never starts X, much less Gnome. If the user is running a cron job, tracker will run, too. I find this incomprehensible, obnoxious and wasteful. So I've expanded my policy of providing these masking links. Now I'm doing it for every user who has a home directory that is not '/' or '/nonexistent'. That means almost all system users and package-provided users, as well as all human users. Maybe I can regain control despite using Gnome. – Steve Newcomb Mar 16 '22 at 15:07
  • 1
    Good reason to disable them: https://twitter.com/kevin_backhouse/status/1711426803997217020 – Daira-Emma Hopwood Oct 27 '23 at 19:42

6 Answers6

6

It turns out that the whole /etc/xdg/autostart/tracker-*.desktop business was misleading in several ways:

  1. There is not a one-to-one correspondence between the tracker daemons and those files. There were 2 such files but there were 3 daemons.

  2. I discovered the existence/identities of the three daemons only by studying the system log.

  3. The trackers are all in userspace. If the user is not running, the tracker daemons don't run. When, on this advice, I used:

    systemctl --user mask tracker-store.service tracker-miner-fs.service tracker-miner-rss.service tracker-extract.service tracker-miner-apps.service tracker-writeback.service

    ... (which as I earlier reported did indeed work), I was creating symlinks in the current user's home directory. In Debian 11/Gnome, these are in ~/.config/systemd/user, for example tracker-extract.service -> /dev/null.

  4. But there's a catch: you have to be logged in as the user whose tracker daemons you wish to disable in order to run systemctl --user .... That's inconvenient for users who are intended to run but not to log in. One such user is Debian-gdm, and evidently by default the tracker daemons run while the gdm greeter is running. Worse, sudo -u thisuser systemctl --user ... refused to work even if I was logged in as root. So, in order to prohibit the tracker daemons from running at all, you must figure out a way to log in as Debian-gdm.

So my current solution to the problem of REALLY disabling the tracker daemons is simply to script the creation and removal of those links in the directories of each affected user. It's important to understand that the names of the symlinks are different depending on whether you're running tracker v2 or v3. It's also important to understand that not all the services named in the above systemctl --user ... are used in all distros. On Debian 11/Gnome, only 3 of the 6 are used, at least so far. It doesn't seem to hurt to mask (create symlinks corresponding to) the unused ones, though.

If the tracker daemons have been running, they have created data whose existence may or may not create security concerns. (Such data are certainly a concern of mine.) To remove these data, the recommended procedure is allegedly:

tracker reset --hard (for v2)
or
tracker3 reset -s -r (allegedly for v3)

But once again, you need to be logged in as the user whose tracker data are to be destroyed. Once again, I found it safer and much easier simply to remove, for each user,

~/.cache/tracker
and
~/.local/share/tracker

or wherever the tracker data happen to be stored.

You may also wish to consider what to do about any prior leakage of verbose tracker reports into the system log.

Pablo A
  • 2,712
Steve Newcomb
  • 371
  • 1
  • 3
  • 6
  • I am using Gnome on Arch Linux. For me, there are no tracker-*.service files. While the XDG Autostart desktop files may spawn a whole bunch of processes running under different users, they appear to be the root of all this tracker stuff. The Arch Linux wiki suggests disabling system-wide XDG entries by creating an identical overriding file in the user's local autostart directory. Thus, I created ~/.config/autostart/tracker-miner-fs-3.desktop containing Hidden=true, which really, completely disabled the filesystem crawler on my system. – kassiopeia Jun 04 '22 at 07:24
5

I had the same problem; I disable it doing:

sudo systemctl --global mask tracker-miner-fs-3.service
sudo systemctl --global mask tracker-xdg-portal-3.service

Of course this should prevent the service to start again for all the users; however if you want to stop the current ones, you should kill them.

I am using debian sid.

kreijack
  • 51
  • Thx, this seems to be the right and simple answer. Worked for me on LMDE6. I deleted about 1GiB of cache using rm -rf ~/.cache/tracker3. I don't understand why this service is enabled by default and why there is no accessible way to disable it. This seems a little crazy to me. – mfg Mar 25 '24 at 20:37
  • This appears to have worked for me , ubuntu kernel 6.5.0-26 – jeremy_rutman Mar 29 '24 at 15:07
4

Recently I had the same problem in my machine, after fresh install, it takes up CPU resources, making pc slow. My solution is changing its values to let it run but make it unable to do any work. Below is the Script with values to set:

#!/usr/bin/env bash

make tracker3 daemon non workable & idompotent


this script will reset its settings, and configure tracker3 daemon, to not let it do anyting.


if other code has dependency on this tracker, then it will not break, but we also do achieve our goal.


interpretation  for org.freedesktop.Tracker3.Miner.Files enable-monitor from this file


https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/miners/fs/tracker-config.c


Time in seconds before crawling filesystem (0->1000)


looking at source code https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/miners/fs/tracker-main.c#L406


it seems like -ve value will starts it right away, so giving max value will make it to wait max before failing


gsettings set org.freedesktop.Tracker3.Miner.Files initial-sleep 1000


Set to false to completely disable any monitoring


gsettings set org.freedesktop.Tracker3.Miner.Files enable-monitors false


Sets the indexing speed (0->20, where 20=slowest speed)


gsettings set org.freedesktop.Tracker3.Miner.Files throttle 20


Set to true to index while running on battery


gsettings set org.freedesktop.Tracker3.Miner.Files index-on-battery false


Set to true to index while running on battery for the first time only


gsettings set org.freedesktop.Tracker3.Miner.Files index-on-battery-first-time false


Set to true to enable traversing mounted directories for removable devices (this includes optical discs)


gsettings set org.freedesktop.Tracker3.Miner.Files index-removable-devices false


Set to true to enable traversing CDs, DVDs, and generally optical media


(if removable devices are not indexed, optical discs won't be either)


gsettings set org.freedesktop.Tracker3.Miner.Files index-optical-discs false


Pause indexer when disk space is <= this value


(0->100, value is in % of $HOME file system, -1=disable pausing)


hmm, seems like this line https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/miners/fs/tracker-main.c#L124


is misleading, as used by some blog, -ve value disable pausing of tracker, rather then tracker itself,


and 100 will make it idompotent as any other value is always < 100%


gsettings set org.freedesktop.Tracker3.Miner.Files low-disk-space-limit 100


List of directories to crawl recursively for indexing (separator=;)


Special values include: (see /etc/xdg/user-dirs.defaults & $HOME/.config/user-dirs.default)


&DESKTOP\n"


&DOCUMENTS\n"


&DOWNLOAD\n"


&MUSIC\n"


&PICTURES\n"


&PUBLIC_SH


&TEMPLATES\n"


&VIDEOS\n"


If $HOME is the default below, it is because $HOME/.config/user-dirs.default was missing.


hmm, i think emptying its value will make it work on all dirs, i probably seen that check somewhere


anyways, redirecting to nonexistent directory will mislead and stop its loop furthur


gsettings set org.freedesktop.Tracker3.Miner.Files index-recursive-directories "['nonexistentdir1']"


List of directories to index but not sub-directories for changes (separator=;)\n"


Special values used for IndexRecursiveDirectories can also be used here"


same with this, as was with index-recursive-directories, but these dirs are removed from index-recursive-directories


so giving it diff value will be more idompotent to this


gsettings set org.freedesktop.Tracker3.Miner.Files index-single-directories "['nonexixtentdir2']"


List of directories to NOT crawl for indexing (separator=;)"


this uses regex, patterns so * will match to everything


gsettings set org.freedesktop.Tracker3.Miner.Files ignored-directories "['*']"


List of directories to NOT crawl for indexing based on child files (separator=;)"


this uses regex, patterns so , ., . will matches to everything


gsettings set org.freedesktop.Tracker3.Miner.Files ignored-directories-with-content "['', '.', '.']"


List of files to NOT index (separator=;)"


this uses regex, patterns so , ., . will matches to everything


gsettings set org.freedesktop.Tracker3.Miner.Files ignored-files "['','.','.']"


Interval in days to check the filesystem is up to date in the database,


maximum is 365, default is -1.


-2 = crawling is disabled entirely


-1 = crawling may occur on startup (if not cleanly shutdown)


0 = crawling is forced


gsettings set org.freedesktop.Tracker3.Miner.Files crawling-interval -2


Threshold in days after which files from removables devices


will be removed from database if not mounted.


0 means never,


maximum is 365.


so, 1 will clear everything, if its stored, daily


gsettings set org.freedesktop.Tracker3.Miner.Files removable-days-threshold  1


hmm, it didn't explain this key behaviour, so i think making it false will be better,


then its default true, As this will disable application indexing


gsettings set org.freedesktop.Tracker3.Miner.Files index-applications false


explaination based on this file:


https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/libtracker-miners-common/tracker-fts-config.c


Flag to enable word stemming utility (default=FALSE)


gsettings set  org.freedesktop.Tracker3.FTS enable-stemmer false


Flag to enable word unaccenting (default=TRUE)


gsettings set  org.freedesktop.Tracker3.FTS enable-unaccent false


Flag to ignore numbers in FTS (default=TRUE)


gsettings set  org.freedesktop.Tracker3.FTS ignore-numbers true


Flag to ignore stop words in FTS (default=TRUE)


gsettings set  org.freedesktop.Tracker3.FTS ignore-stop-words true


explaination based on this file:


https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/tracker-extract/tracker-config.c


Maximum number of UTF-8 bytes to extract per file [0->10485760]


min ==> 0 ==> 0b


max ==> 1024 * 1024 * 10 ==>  10 Mb


default ==> 1024 * 1024  ==> 1Mb


gsettings set org.freedesktop.Tracker3.Extract  max-bytes 0


Filename patterns for plain text documents that should be indexed


empty, as these are whitelisting pattern, or maybe never existent filename pattern


will also work, like filename that contains new line in it, will make it to never match


to anything.


gsettings set org.freedesktop.Tracker3.Extract  text-allowlist '[]'


Wait for FS miner to be done before extracting


%TRUE to wait for tracker-miner-fs is done before extracting. %FAlSE otherwise


hmm, true will make it less aggressive, as it will wait for miner to finish which


itself has 1000s initial delay.


gsettings set org.freedesktop.Tracker3.Extract  wait-for-miner-fs true


disable its settings in gnome settings also


populate disable list, disable all apps, and location


gsettings set org.gnome.desktop.search-providers disabled "['org.gnome.Terminal.desktop', 'org.gnome.Settings.desktop', 'org.gnome.Photos.desktop', 'org.gnome.clocks.desktop', 'org.gnome.Calendar.desktop', 'org.gnome.Calculator.desktop', 'org.gnome.Nautilus.desktop']"


clear enable list


gsettings set org.gnome.desktop.search-providers enabled "[]"


search path setting is already cleared in "index-recursive-directories"


disable gnome search indexing itself


gsettings set org.gnome.desktop.search-providers disable-external true


and finally,


Application Options:


-s, --filesystem     Remove filesystem indexer database


-r, --rss            Remove RSS indexer database


tracker3 reset -s -r


and kill it brutally


tracker3 daemon --kill

Alternatively, checkout this gist of mine: make gnome tracker disable or stop completely.

Pablo A
  • 2,712
dinesh saini
  • 141
1

This is how you completely get rid of it :

sudo apt remove tracker tracker-extract tracker-miner-fs

Did the trick on ubuntu. After that , you can reboot or kill the tracker process(es). His trash will be in .cache folder e.g.

/home/$USER/.cache/tacker*

And can install via

sudo apt install tracker-miner-fs
Murat Aka
  • 19
  • 5
    This will also uninstall ubuntu desktop and Nautilus (the visual files broser). I should say so or your comment will break some peoples ubuntu installation – Sxubach Jun 20 '23 at 12:38
  • Worked great, after installing cinnamon-desktop-environment and switching to a cinnamon session. – moooeeeep Sep 22 '23 at 10:00
1

I kind of redirected the tracker- services to bin/true. It is less invasive. Since they are user-level services, create override directories and override the services in your home, e.g.:

#! /bin/bash
for t in tracker-extract tracker-miner-fs tracker-store tracker-writeback; do
  SVD=${HOME}/.config/systemd/user/${t}.service.d
  if [ ! -d ${SVD} ]; then
    mkdir -p ${SVD}
  fi
cat > ${SVD}/override.conf << EOF
[Service]
Type=
Type=oneshot
ExecStart=
ExecStart=/bin/true
Restart=
Restart=no
EOF
done

I am using debian 11

Gort
  • 11
1

Why do you want to disable those daemons?

This comment was made above, for me using RHEL 7.9, and now RHEL 8.9, in a work environment users will get a /home/<account>/.cache/tracker folder and we have had this folder get to over 100gb for multiple users who are running various software and simulations and then causing the system to lock up because either the /home partition is full or the entire disk becomes full. This is in addition to cpu being used when it we want 100% cpu to be running on software we are executing. Needless to say, gnome tracker is bad, we don't see any good reason to use it and it has done more harm than good.

Doing a yum remove tracker looks like a no go because of so many dependencies it tries to also remove, the gnome-classic-session being one of them.

in RHEL 8.9 here is the most elegant way I have found to disable it and remove and prevent the .cache/tracker folder from ever reappearing. Create an /etc/profile.d script as shown below, having a .sh or .csh suffix to the filename as appropriate.

# /etc/profile.d/stopgnometracker.sh

perform for the root account once manually, the if statement here prevents a dbus error message when doing an su or sudo to root


if [ "$LOGNAME" != root ] && [ "id -u" -ne 0 ] ; then


systemctl --user mask tracker-store.service tracker-miner-fs.service tracker-miner-rss.service tracker-extract.service tracker-miner-apps.service tracker-writeback.service > /dev/null  2>&1


tracker daemon --kill > /dev/null 2>&1


rm -rf ~/.cache/tracker


fi
ron
  • 6,575