Install tracker by default in 18.04 LTS?

Doing regular backups with deja-dup (duplicity as the backend), I notice that tracker is taking a lot of core and CPU everytime a backup is performed (and you can see the disk is hammered), even if it’s supposively only read operations on that side.

1 Like

That’s not my experience. My personal desktop, does backups daily using deja-dup (Gnome’s backup utility). My 8 cores never get more than 30% during, and haven’t noticed any disk I|O usage of any significance. The only settings that aren’t default on my box is Tracker being set to ‘low-priority’ and I don’t have the destination drive for backups enabled for indexing via the search settings in Gnome-Control-Panel.


Well, all the Ubuntu 17.4 and Budgie 17.4 anectodes are certainly entertaining to read, but there was a big overhaul in between then and now with the jump from Tracker1 to Tracker2. Chances are that Tracker 2 (Ubuntu 17.10.) is much lighter on resources than old Tracker 1. So old Tracker1 experiences don’t seem too worthwhile.

And CPU cycles and RAM are meant to be used (unless in a power saving mode). I think that it is more important that Tracker goes out of the way easily if the resources are needed by other tasks, indexing just when being eg. idle.

When aiming to save RAM and cycles I would rather try to stop GDM3 sitting in the background for little gain. Collecting data IS worthwhile, for faster searches, for faster program start ups and so on.

And more and more GNOME features start to use tracker, so it will get harder and harder to avoid installing it. I think it would be more future-proof to help sorting out the problems instead investing resources to avoid it (eg. patching out features that depend on it).


I guess I better add my +1 vote in here then. :slight_smile:

I don’t even remember installing tracker - maybe I got it via a dependency from something else - but I’ve had it on my system for ages. If I notice something behaving badly on my system, it’s usually Firefox - never in my memory have I felt like Tracker was responsible for any bad behaviour.

Yesterday I needed to search in my ~/Documents for a PDF that I knew mentioned the word “treasurer”, but I couldn’t remember the filename of. Thanks to having Tracker installed, I was able to type “treasurer” into Nautilus and it found the file instantly. That was really great.

smem’s “PSS” pins 7610+12256+13393+16152 = 49411K on all tracker processes on my system ATM.

So my Laneyish vote is to go for it and get some targetted and actionable bug reports that we can work on, like if there is a memory leak that is affecting initial indexing, or if something weird happens in the backup usecase.

1 Like

@jbicha thanks a ton for the clarification. I appreciate it. Hopefully our little blurb was helpful. :slight_smile:

That’s interesting reading about tracker 1 vs 2. May do some additional testing. The larger take away for us (u budgie) was a drop in support issues. With that being said, will likely play around.


But also since Jeremy mentioned that this doesn’t cause the flavors to go in one direction or the other, or vote/feedback might be kind of moot.

@fossfreedom / @GrindamN - just for visibility.

1 Like

Just as a user I think this should be an option for the install, not a “default” on thing.

I’ve tested tracker a few times (and I’m currently running it on 17.10) the only time I noticed any “lag” or problems with it are connecting/disconnecting drives (external USB has been the worst for me) although I think that could be fixed in the config (I’m just testing it as the stock at the mo, haven’t changed anything… yet).

Other than that it seems to eat CPU time and MEM on a fresh install, but after about two or so hours (depends on the number of files it has to index obviously) it drops right down and basically remains unnoticable (so far atleast).

Only been running it for around a week or so, so it’s not really been hammered yet.


I don’t know if this is related to tracker but nautilus freezes for me when I try to copy anything from nautilus, not just files but also file names while renaming. On my desktop tracker can get out of control and eat my whole ram and crash the system.

Gnome tracker is dreadful, and I mean DREADFUL, I installed it in 17.10 and it is eating CPU and RAM like crazy and it is far less effective than search in Unity dash or KDE with Baloo. The fact you cannot turn off indexing file content probably contributes a lot to this, I would like it preinstalled, but only if there is a toggle in System Settings where we can disable indexing file contents, KDE’s Baloo indexes hundreds of thousands of files on my partitions VERY quickly when I turn off file content indexing (which usually does not serve much purpose anyway for me). Unity dash search is sorely missed in this new desktop, but tracker has poor performance with its file content indexing turned on by default, I havent been able to find any configuration files where I can turn it off and even if they existed users should be given the GUI option of disabling indexing file contents in System Settings. I believe turning on indexing (without file contents indexing) by default on all partitions mounted in fstab would be the best solution that would mimic the Unity dash the most.

1 Like

I like tracker a lot, I’m using it several years already.

But regurlarly, about 3 times a week, I experience serious performance issues, mainly IO-bound. My system is completely unresponsive at those moments.

The reindexing should be performed nightly, but it starts at the most unpredicable times.

Pre-install with hooks for:

  1. Expose toggle in ‘Settings’ for ‘LOW | MED | HIGH’ priority [low by default?]

  2. Only run when connected to AC power [never on battery?]

  3. Make sure bin file is named appropriately for easy discovery by ‘average/newb’ sys-admin when viewing in Sys-Mon apps of process trees. Die/HUP gracefully for test purposes when it is suspected of impacting performance. [uninstallable at any time?]

P.S. Windows 10 has a background indexer called: “Windows Search” and a ‘preload’ type service called “Superfetch” that peg the hard drive at 100% usage when booting and for quite some time afterwards in the user session. Annoying as heck when using in a gnome-boxes session for that occasional Windows requirement. Let’s do better !!


It’s very useful and necessary in my opinion, but I experienced CPU and disk I/O performance lose, badly, like system hanged. I let tracker-store and tracker-extract work about 6 hours, but wasn’t enough and they didn’t finish! (using fresh artful x64)

No need to explain anymore, since above replays are enough. I'm a developer and use "-j8" for compilation, and need maximum CPU performance, then I prefer no indexing.

So, my recommendation is, "No" default installation

Thank you all

Please file a bug. Thanks.

I installed tracker yesterday. After an initial spike in CPU and Disk I/O because of indexing (which didn’t take that long at all), I have not experienced any drawbacks. Using Ubuntu 17.10 on an XPS 13 9360.

1 Like

I am using 17.10 (now with Gnome) upgraded over many versions, I don’t know when tracker got installed. It seems to causes no problems on my system and I find the search from the Dash (or whatever it is called in Gnome) useful. I miss the flexibility of setup with tracker-gui which was there on 17.04.

Apparently, I’ve had tracker installed for a while on 17.10. (set to automatically installed, so it must’ve been a dependency of something…) Haven’t had any issues with 17.10 (except from Wayland bugs), so +1 for installing it by default!

Also important: including tracker opens up the road to include Gnome Photos. I think it’s a lot better than shotwell, and it’s receiving many improvements:


The feedback here seems to have been mostly good but showed that some users are hitting bugs. In any case such changes are risky in a LTS cycle and it’s getting late in the cycle now/other work still didn’t land. Let’s discuss that at the weekly meeting tomorrow but I suggest we do the change next cycle postLTS, it should give us plenty of room for testing without putting the LTS at risk.

1 Like

The topic was discussed in the meeting and it was decided to not use it for the LTS but install it by default next cycle.

1 Like

Closing since this issue has a clear resolution.