Bug 747689 - provide a method to disable tracker
provide a method to disable tracker
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: tracker (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Igor Gnatenko
Fedora Extras Quality Assurance
: FutureFeature, Reopened, Tracking, UserExperience
: 1432108 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-20 15:16 EDT by Jeff Bastian
Modified: 2017-07-11 08 EDT (History)
52 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-04 13:07:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
script to disable tracker for all users from /etc/profile.d (570 bytes, text/plain)
2015-10-20 16:56 EDT, Gerd v. Egidy
no flags Details
Puppet definition to disable autostart (478 bytes, text/plain)
2017-07-11 08:24 EDT, loopsysdev
no flags Details

  None (edit)
Description Jeff Bastian 2011-10-20 15:16:49 EDT
Description of problem:
I have 3 tracker daemons running and two are hogging my CPU:
  $ pgrep -lf tracker
  2219 /usr/libexec/tracker-miner-flickr
  2225 /usr/libexec/tracker-miner-fs
  2266 /usr/libexec/tracker-store

top output:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND             
 2225 jbastian  39  19  754m 248m 243m R 76.2  6.6   2:03.28 tracker-miner-f     
 2266 jbastian  20   0  801m 274m 242m S 21.2  7.3   2:43.20 tracker-store 

I don't even use flickr, so why do I have a daemon for it?

And I use KDE, so I already have Nepomuk + Strigi for indexing, so why is there a second indexing service running?

I launched tracker-preferences and turned off all the check-boxes, but it's still running.

Please provide a method to disable tracker.


Version-Release number of selected component (if applicable):
tracker-0.12.4-2.fc16.x86_64

How reproducible:
every time

Steps to Reproduce:
1. boot and login to KDE
2. pgrep -lf tracker
3. top
  
Actual results:
three tracker processes are running and using lots of CPU

Expected results:
a way to disable tracker

Additional info:
For now I just removed /etc/xdg/autostart/tracker* because if I try to 'yum remove tracker' it wants to remove a number of other packages like totem that are useful.
Comment 1 Jeff Bastian 2011-12-01 14:48:31 EST
A cleaner way to disable tracker is to create a personal autostart file to override the system file.  This only works on a per-user basis, though.

Create 3 files:

~/.config/autostart/tracker-miner-flickr.desktop
~/.config/autostart/tracker-miner-fs.desktop
~/.config/autostart/tracker-store.desktop

The contents of all 3 files should be:

[Desktop Entry]
Hidden=true
Comment 2 Jeff Bastian 2011-12-01 15:30:36 EST
Well, that worked for KDE and Xfce anyway.

Gnome Shell seems to have its own method with X-GNOME-Autostart-enabled=false plus a lot more.  It's best to just run gnome-session-properties and uncheck the boxes for the Tracker services.

Note: if you already followed comment 1, remove the ~/.config/autostart/tracker* files before running gnome-session-properties or else you won't see the Tracker entries because, well, they're Hidden.
Comment 3 RogerOdle 2011-12-25 23:46:48 EST
I do not want this package installed. Totem lists it as a dependency though I know of no essential function that it provides to Totem.  Helper features like these need to be added as options that are not required to be installed.  This type of index functions is one of the primary features to be disabled on Windows when optimizing its performance. Now this same performance killing feature has been ported to Linux with the same expected results.  I almost never search my file system and do not want or need to waste CPU and file resources building and maintaining indexes for it.  Since I have installed FC16 on one of my laptops, the laptop has mysteriously frozen up after USB drives have been installed.  I had to reset with the power button to restore normal operation.  After the laptop restarted, I opened a terminal and ran top.  This listed tracker-miner-fs consuming most of the CPU.  I do not like having to disable features like this with hidden menus.  Anything that can effect performance like this should be configurable under system-settings but gnome-sessions-properties can not be accessed though this common system tool.  That seems like an oversight.  To sum up, I would prefer to not install this in the first place, if I can not do that, then I want to tool that disables it to be located in the one place where I go to configure other the system features. Fix it if you want it but give the rest of us the ability to run a usable system without it.
Comment 4 Alan Brault 2012-01-11 20:42:41 EST
I have to concur with the following gentlemen in this bug report about tracker. This utility is just as bad as the mono powered beagle in that while the concept in principal is fine, the execution is not. Much like beagle, tracker is extremely inefficient on the CPU and when working on certain environments (such as Virtual Machines) or systems with SSD or USB drives it can cause serious performance hinderances.

Currently the only ways to disable this tool are as follows:

:: Using gnome-session-properties
:: Editing the files ~/.config/autostart
:: Editing the files /etc/xdg/autostart

For the novice user this is not ideal and there should be a more direct option to disable this in System Properties or have it disabled by default or detect certain system environments and disable it (anaconda does this with kdump) such as Virtual Machines, Netbooks and certain Notebooks.
Comment 5 Alan Brault 2012-01-11 20:49:20 EST
Addendum:

I should also point out, which I failed to do more properly in the previous post. That this application tends to inexplicitly run during other intensive processes such as ripping music, extracting large archives, compiling or anything dealing with I/O against the file system. My guess is this is due to the detection of changes on the file system and it's insistence on indexing it. This is another example of poor inefficiency (and for awhile, beagle was guilty of this as well).
Comment 6 Jimmy Dorff 2012-03-13 11:13:39 EDT
This type of tool doesn't fit well in some environments. There must be a way to globally disable / remove this package.
Comment 7 Ian Donaldson 2012-03-19 21:46:22 EDT
This seems to work pretty well for me.  YMMV.


rpm -e --nodeps tracker brasero brasero-nautilus
Comment 8 Jonathan Ryshpan 2012-03-22 03:12:05 EDT
(In reply to comment #7)
> rpm -e --nodeps tracker brasero brasero-nautilus

Why is it necessary or desirable to remove brasero?
Comment 9 Ian Donaldson 2012-03-22 03:22:03 EDT
Possibly not necessary; just  less lines of complaint from 'yum check',
and I don't need it.
Comment 10 Jonathan Ryshpan 2012-03-22 03:27:54 EDT
A comment on the web advises that this can be done via a Gnome GUI:

http://ask.fedoraproject.org/question/131/how-do-i-disable-tracker
...
You can do the same using UI - run gnome-session-properties in a terminal and unclick all three items there. Restart.
lzap (Nov 19 '11)
Comment 11 Ian Donaldson 2012-03-22 03:41:49 EDT
Coupla things here:

- we use KDE here, not Gnome.  Does that doco apply in this case?

- I don't want this resource hog enabled for any of my staff, 
  as it will kill our NFS servers (where their home directories are)
  if it behaves the way I've seen so far.

  I thus want a system-wide default for this and I don't want a staff member
  to be able to reverse this policy by accidental fiddling with settings;
  rpm -e provides me this fairly well.

  I also don't want to have to update everybody's profiles for this; 
  an rpm -e achieves what I want in a one-liner after the system is installed
  or upgraded.
Comment 12 Jonathan Ryshpan 2012-03-22 08:49:40 EDT
(In reply to comment #11) 
> - we use KDE here, not Gnome.  Does that doco apply in this case?

So do I.  gnome-session-properties is part of the gnome-session RPM, which I installed (I think) to be able to experiment with the Gnome desktop.  The doco is applicable if this RPM is installed.

> - I don't want this resource hog enabled for any of my staff, 
>   as it will kill our NFS servers (where their home directories are)
>   if it behaves the way I've seen so far.
> 
>   I thus want a system-wide default for this and I don't want a staff member
>   to be able to reverse this policy by accidental fiddling with settings;
>   rpm -e provides me this fairly well.

Advice for this is in Comment 4.  I think the places to edit are in 
/etc/xdg/autostart/tracker* at lines starting "X-GNOME-Autostart-enabled=true".  I prefer to use automatic gadgets when I can, since they require less brainpower.

>   I also don't want to have to update everybody's profiles for this; 
>   an rpm -e achieves what I want in a one-liner after the system is installed
>   or upgraded.

Vide supra.

BTW: Having tracker as a requirement for installing totem or brasero is (in my opinion) very bad.
Comment 13 Jeff Bastian 2012-03-22 09:56:08 EDT
(In reply to comment #7)
> This seems to work pretty well for me.  YMMV.
> 
> 
> rpm -e --nodeps tracker brasero brasero-nautilus

You may want to add
  exclude=tracker*
to /etc/yum.conf or else tracker may get re-installed if another package which depends on tracker is updated.

For example, if 'yum update' pulls in a new totem package, it will install tracker too to meet totem's dependencies.
Comment 14 Ian Donaldson 2012-03-24 05:28:46 EDT
Tried editing /etc/xdg/autostart/tracker* ... set X-GNOME-Autostart-enabled=false
but that had no effect on KDE, as you would tend to expect.

There are KDE related options there too, eg:

X-KDE-autostart-after=panel
X-KDE-StartupNotify=false
X-KDE-UniqueApplet=true

but I don't know whether changing one of those (and what to set it to)
would work.

So I commented these 3 out, and... still had no effect.

Back to plan B.  rpm -e ...
Comment 15 Andrew McNabb 2012-06-07 18:34:34 EDT
There still doesn't appear to be a reasonable way to disable tracker in Fedora 17.
Comment 16 Jimmy Dorff 2012-06-13 15:11:48 EDT
Suggestion from Paul Frields at South East Linux Fest which seems to be working with some limited testing on Fedora 17.

I have created this file:
"/usr/share/glib-2.0/schema/org.freedesktop.Tracker.Miner.Files.gschema.override"

with the contents:
[org.freedesktop.Tracker.Miner.Files]
crawling-interval=-2
enable-monitors=false

You then run "glib-compile-schemas /usr/share/glib-2.0/schemas/".

I can test this worked as a regular user by running:
$ gsettings get org.freedesktop.Tracker.Miner.Files crawling-interval
$ gsettings get org.freedesktop.Tracker.Miner.Files enable-monitors

After logining in with these settings, I have not seen updates to  ~/.local/share/tracker which I was seeing before the updates. Tracker is still running, but since we have disabled crawling and disabled monitoring for changes, it shouldn't *do* anything.

Also, since we have used a "Vendor override file" to change the defaults it should apply to all users who don't have a specific setting already.
Comment 17 Patrick Mansfield 2012-07-18 12:36:03 EDT
(In reply to comment #16)
> Suggestion from Paul Frields at South East Linux Fest which seems to be
> working with some limited testing on Fedora 17.
> 
> I have created this file:
> "/usr/share/glib-2.0/schema/org.freedesktop.Tracker.Miner.Files.gschema.
> override"

Note the above should be "schemas" not "schema"

> with the contents:
> [org.freedesktop.Tracker.Miner.Files]
> crawling-interval=-2
> enable-monitors=false
> 
> You then run "glib-compile-schemas /usr/share/glib-2.0/schemas/".
> 
> I can test this worked as a regular user by running:
> $ gsettings get org.freedesktop.Tracker.Miner.Files crawling-interval
> $ gsettings get org.freedesktop.Tracker.Miner.Files enable-monitors
> 
> After logining in with these settings, I have not seen updates to 
> ~/.local/share/tracker which I was seeing before the updates. Tracker is
> still running, but since we have disabled crawling and disabled monitoring
> for changes, it shouldn't *do* anything.

The above did not work for me, tracker-store is still doing something :-(

I can see it has files open under ~/.cache/tracker
Comment 18 Patrick Mansfield 2012-07-18 12:51:51 EDT
And removing tracker seems to cause "klipper" to fail :-(
Comment 19 Patrick Mansfield 2012-07-22 13:23:16 EDT
(In reply to comment #18)
> And removing tracker seems to cause "klipper" to fail :-(

klipper is showing up for me (though not always), so I don't think that is related to the removal of tracker.
Comment 20 Elliott Forney 2012-08-09 16:15:47 EDT
tracker is causing huge problems for us.  We have NFS shared home directories and having tons of these processes running simultaneously slows NFS to a crawl.

It would definitely be nice to be able to disable this without removing totem and brasero.
Comment 21 Elliott Forney 2012-08-09 16:21:25 EDT
I might also note that workarounds like modifying files in /etc/xdg/autostart/* will get blown away by updates to the tracker rpm.  So, this isn't a permanent fix.  Also, having individual users doesn't do the trick in environments with 1000's of users.
Comment 22 Gerd v. Egidy 2012-08-09 16:49:05 EDT
> tracker is causing huge problems for us.  We have NFS shared home directories 
> and having tons of these processes running simultaneously slows NFS to a crawl.

I have exactly the same problem.

As an easy way for an admin and the maintainer to fix this, I proposed the solution in Bug #842318.

But until that is done I regularly run a script on the nfs server to create these files every users homedir:
~/.config/autostart/tracker-store.desktop
~/.config/autostart/tracker-miner-fs.desktop
~/.config/autostart/tracker-miner-flickr.desktop

Each of them contains:
[Desktop Entry]
Hidden=true
X-GNOME-Autostart-enabled=false

Autostart files with the same name in the users homedir take precedence over the stuff in the system dir. So tracker stayes off.
Comment 23 Andrew McNabb 2012-08-09 17:52:40 EDT
(In reply to comment #21)
> I might also note that workarounds like modifying files in
> /etc/xdg/autostart/* will get blown away by updates to the tracker rpm.  So,
> this isn't a permanent fix.  Also, having individual users doesn't do the
> trick in environments with 1000's of users.

If you delete the files in /etc/xdg/autostart, then they'll get rewritten by upgraded packages, but if you create an empty file in that directory, it won't get overwritten. My workaround has been to replace the files with basically empty files (which just contain a comment explaining why the file is even there).
Comment 24 udo.rader 2012-08-14 06:27:21 EDT
suffering from this stupid resource monster as well, comment#3 says it all ...

Our way to fight the beast is to add this line to all users' .profile and/or .bashrc files:

[ -e /usr/bin/tracker-control ] && [ -x /usr/bin/tracker-control ] && /usr/bin/tracker-control -r > /dev/null
Comment 25 Jeff Bastian 2012-09-13 11:13:05 EDT
FYI, bug 771601 is addressing this for KDE and Xfce.
Comment 26 Bradley 2013-07-02 12:52:25 EDT
On Fedora 19, tracker is still a problem.  It was using 2 GB of RAM alone!

I think the root of the problem is that tracker caches samba shares as well.  At work, I need to open up different samba shares, some with terabytes of data.

Anyone know of a way to make tracker exclude certain folders/mounts?

For now, I disabled all tracker processes.  I used "gnome-session-properties" and added "tracker-control -r" to startup.  I also deleted my over-bloated ~/.cache folder.

If the upstream maintainers of tracker would just add a CPU & RAM cap (with ulimit?), then I'd be happy.  Set the default to ~5% CPU and ~128 MB.
Comment 27 Fedora End Of Life 2013-07-04 01:22:30 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 28 Steve Tyler 2013-08-09 03:02:26 EDT
The packages that will be removed, if tracker is removed, can be listed with repoquery. For a full list of packages that require tracker, omit the "--installed" option:

$ repoquery --arch=x86_64 --whatrequires --recursive --installed tracker | wc -l
10

$ repoquery --arch=x86_64 --whatrequires --recursive --installed tracker
evince-nautilus-0:3.8.3-1.fc19.x86_64
file-roller-nautilus-0:3.8.3-1.fc19.x86_64
gnome-boxes-0:3.8.3-1.fc19.x86_64
gnome-tweak-tool-0:3.8.1-1.fc19.noarch
grilo-plugins-0:0.2.8-2.fc19.x86_64
nautilus-0:3.8.2-1.fc19.x86_64
nautilus-extensions-0:3.8.2-1.fc19.x86_64
totem-1:3.8.2-1.fc19.x86_64
totem-nautilus-1:3.8.2-1.fc19.x86_64
tracker-0:0.16.1-3.fc19.x86_64
Comment 29 Steve Tyler 2013-08-09 03:27:06 EDT
See Bug 821952, Comment 3:
Bastien Nocera 2013-05-29 12:23:42 UTC

"The tracker plugin is going to be a hard dependency of both Totem and gnome-music. So splitting off the daemon, or the plugin isn't going to help anything."


NB: These components have explicit bugs:
grilo-plugins:  Bug 821952 - Make tracker plugin optional (CLOSED WONTFIX)
nautilus:       Bug 867925 - dependency to tracker universe (NEW)
Comment 30 Steve Tyler 2013-08-09 06:53:49 EDT
Two bugs against brasero for tracker dependency.
NB: The second is a clone of the first.

brasero:
Bug 796349 - CLOSED WONTFIX - Xavier Lamien - brasero has dependency on tracker
Bug 947529 - NEW  - Xavier Lamien - brasero has dependency on tracker

Found with the help of the excellent python-bugzilla package and this custom shell script:

$ cat bz-reports-about-packages-requiring-tracker-1.sh
#!/bin/bash

CLIST=$(repoquery --arch=x86_64 --whatrequires --recursive tracker | egrep -v 'tracker|devel' | cut -d ':' -f1 | sed 's/-.$//' | uniq)

for c in $CLIST; do
  echo "$c:"
  #bugzilla query -c $c -s tracker | sed 's/^#/Bug /'
  bugzilla query -c $c -s tracker --outputformat='Bug %{id} - %{status} %{resolution} - %{assigned_to} - %{summary}'
  sleep 0.1
done

==
$ rpm -q python-bugzilla 
python-bugzilla-0.9.0-1.fc19.noarch
Comment 31 Elliott Forney 2013-08-09 16:35:27 EDT
Given the dependencies, it seems likely that many users will not be able to uninstall tracker.

Wouldn't it just work to have the files

/etc/xdg/autostart/tracker*.desktop

be listed as %config(noreplace) in the rpm .spec file.  That way changes won't get blown away by updates.

Then, a sysadmin can prevent tracker from starting (at least by default) by setting

Exec=/bin/false

In these files.  If a user has good reason to use tracker, then they can override this in ~/.config/autostart.
Comment 32 Elliott Forney 2013-08-09 16:40:10 EDT
Wait... hasn't this bug already been resolved in the following?

Bug 842318


I wish there was a general tool for selecting what gets autostarted by default.  I have run into this several times.
Comment 33 Roger Odle 2013-08-09 20:30:10 EDT
Why should we have to do something complex to fix this? I would prefer something like a system policy for services where services are classified by functions rather than by name.  If the policy is set to disallow system indexing then no system indexers are allowed to run period.  You do not need to know the minutia of every system package.  If a packages does not comply with the system policy mechanism then do not include it in the distro in the first place.

The way it is now, I have to google these mysterious services to find out that I never wanted them in the first place.  And now in Fedora 19, a lot of mysterious, anonymous kernel processes are listed by top.  They all have generic names that do not really indicate what they do. (Maybe, they shouldn't be listed as "processes" anyway if they are really doing something internal to the kernel)  Now I have something else to worry about.  I build embedded systems with Linux and I have to know what my system is doing.  I need systems that do the things they need to be doing and do not do the things that they do not need to be doing.  A service that does nothing should not be loaded and occupying CPU time or memory space.  Everything that a system does is something that it could do wrong. In the quality assurance/reliability aspects of a design, everything has some finite probability of failure and you have to combine all of those probabilities to determine reliability.  The more you do the less reliable your system can be.  Making these desktop systems more like Apple and Microsoft do is making Linux unstable like Apple and Microsoft products are.  Aside from the security problems these systems have, they crash all too often for bad reasons.  We can, and should, be better than they do.

Many people have now indicated a need for a system without tracker.  They have provided information on how to disable it but removing it would be cleaner.  In the future, I would like the packaging system to warn me that a package that I am installing will include a service which is going to run automatically and ask (at install time) if I want that service installed or if I want to allow it to run automatically if it is installed.  That way, I do not have to find out after the fact that I have to clean up my services again.
Comment 34 Doncho N. Gunchev 2013-11-11 21:09:23 EST
Can't the tracker package be split in two - one with the autostart bits (tracker-autostart) and another for the rest. This way it will be installed, nautilus and whatever else needs the libraries will have them and it won't get autostarted?
Comment 35 Ian Donaldson 2013-11-11 21:48:58 EST
Here's a radical thought; modify tracker to not do anything on
a filesystem that is not locally connected by *default*.

How it determines that a fs is local I'm not 100% sure; statfs(2) returns
a f_ftype so perhaps NFS_SUPER_MAGIC could be excluded; there may
be others.

The default should not be overridable by users if the system admin
policy has it disabled though.
Comment 36 Elliott Forney 2013-11-11 23:18:10 EST
I agree with Ian that tracker should probably not act on network filesystems.  This would be a similar approach to that taken by mlocate, see /etc/cron.daily/mlocate for details on how it does this.

I still wish there was a way to modify the defaults in /etc/xdg/autostart/* without being blown away by the package manager, but that aside, it doesn't really make any since for tracker to look at NFS.
Comment 37 Yannick Defais 2013-12-30 14:04:58 EST
In Fedora 20, tracker does not shows up in gnome-session-properties.

I tried to put Exec=/bin/false in /etc/xdg/autostart/tracker*.desktop, but it did not works.

Only solution I found was the one in comment 24 :
https://bugzilla.redhat.com/show_bug.cgi?id=747689#c24
Comment 38 Yannick Defais 2014-01-02 17:44:28 EST
In Fedora 20 it is even worst : I kill tracker a each session startup, but if I write a file in home it comes back from the dead !

How can we stop tracker once for all ?
Comment 39 sixpack13 2014-01-24 14:08:56 EST
Yannick

I do 

sudo chmod -x /usr/libexec/tracker*


side effects ??? 
I don't know !


you need to do it again, when tracker got updates !!!
Comment 40 Elliott Forney 2014-01-24 17:06:16 EST
sixpack13:  This won't persist.  The next time there is an update to the package the permissions will change back.
Comment 41 sixpack13 2014-01-24 18:07:25 EST
yep, I mentioned it already #39.
last sentence


okay, put it in /etc/rc.d/rc.local.
this file doesn't exist per default since fedora 18, 19, ???

1. great one !

maybe like this(without warranty):

#!/bin/bash
touch /var/lock/subsys/local

/usr/bin/chmod -x /usr/libexc/tracker*;

exit 0;


2. sudo chown root.root /etc/rc.d/rc.local
3. sudo chmod 700 or 755 /etc/rc.d/rc.local

4. reboot or source /etc/rc.d/rc.local

5. relax :-)

systemd will pick it up during *next* boot -IFAIK- automatically

check with: systemctl status rc-local.service
Comment 42 sixpack13 2014-01-24 18:23:48 EST
Arrrggghhhh !

Typo in libexec:

in line "/usr/bin/chmod -x /usr/libexc/tracker*;"

s/libexc/libexec/

OR

sudo sed -i -e 's/libexc/libexec/' /etc/rc.d/rc.local
Comment 43 CBaxter 2014-06-16 07:32:02 EDT
Changing ~/.profile as given Comment 24 worked for me. No more tracker - bliss. I'm running Debian 7 and openbox.
Comment 44 Christopher Meng 2014-06-18 03:13:43 EDT
Using gsettings to disable following options regarding indexing:

gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2
gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false

*Then hard reset the tracker with*: 

tracker-control -r
Comment 45 Fedora Admin XMLRPC Client 2014-07-26 13:10:38 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 46 Fedora Admin XMLRPC Client 2014-07-27 02:32:38 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 47 javiertury 2014-08-01 20:17:29 EDT
The main problem is not the method to disable tracker(which would be nice) but tracker itself. My laptop has 8GB of ram and using only gnome-shell with tracker-miner-fs uses 2GB of ram without cache and buffers, and counting cache and buffers it uses all my memory, 8GB! Also, some time ago it randomly used high cpu loads, but this issue seems to have been fixed.

This is clearly a problem of tracker, I think it should be disabled by default until it reaches a more stable state since this issue haven't been solved for years.

Should we also open a new bug against tracker itself so hopefully tracker is fixed?
Comment 48 Gerry Reno 2014-09-23 02:04:27 EDT
Here's another vote to make tracker go away.
This thing is hogging my CPU and burning out my hard drives.
Why is this even installed on xfce desktop install?
I try to uninstall it and there are 16 package dependencies on it.
This is the same nonsense that went on with Beagle.
Comment 49 Jean-François Fortin Tam 2014-10-13 20:31:53 EDT
Nautilus has a --disable-tracker compile-time switch, AFAIK.
I'm suspecting this means that even if you have Tracker installed, it won't use it; what I'd like to see instead is that by default, there is no hard dependency; it uses Tracker if present, otherwise just carries on. But that's not the case, I suppose?
Comment 50 sheepdestroyer 2014-11-17 01:15:14 EST
still a problem in fedora 21
Comment 51 Ian Donaldson 2015-01-05 21:08:53 EST
fc21 also comes with baloo-file, yet another disk thrashing indexer enabled
by default for all users.  Totally inappropriate in an NFS based shared desktop 
environment.

My workaround so-far is to do this:  rpm -e baloo-file
ad add it to 'exclude' in /etc/yum.conf to keep it from returning.

Luckily there doesn't seem to be any dependencies, unlike tracker.
Comment 52 Fedora End Of Life 2015-01-09 11:49:45 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 53 Gerd v. Egidy 2015-01-09 12:18:32 EST
still a problem in fedora 21 -> changing version
Comment 54 Piergiorgio Sartor 2015-01-10 08:25:02 EST
Hi all,

I just found another reason while "tracker" should be blocked/disabled/removed. 
As for F21, it is spamming "/var/log/messages" with users files *content*, just for the sake of privacy...

See also:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754907

In general, it would be nice *not* to have these indexing tools active per default, since it is not clear how safe is the collected information.
Of course, each user can disable it, but it would be better to have it disabled by default and inform the user about the risks of enabling it (namely, that some information will be plain text available in the $HOME folder).
Even using ~/Private will not help, since the DB is somewhere else (can be moved there, but then again what the heck...).
And no, full disk encryption does not work in multi-user systems...

Furthermore, why other tools, like "nautilus" or "brasero" depend on these things? As stated in some other comment, it should be optional, not mandatory. That is, if present, can be used, otherwise, just ignore.

Of course, if I remove "tracker" with "nodeps", then "nautilus" and "brasero" do not work anymore (cannot find library), which is not acceptable too.

In order to conclude, here's one more vote to make tracker go away.

Thanks,

bye,

pg
Comment 55 Piergiorgio Sartor 2015-01-10 11:05:53 EST
Hi all,

there is another thing I just noticed.

The information leaked into /var/log/messages does belong, as well as the one stored in the DB, I suppose, to files stored in ~/Private.

Basically, this nice tool, reverts the safety of the encrypted storage into completely unsafe storage.

So, I'm a bit puzzled on why this bug is set to "rawhide", why is set as "Enhancement", why "FutureFeature" and why the "severity" is "medium".

This is *urgent* and *critical", since it hinders completely the concept of having a "Private" folder.

Could you, please, act accordingly?

Thanks,

bye,

pg
Comment 56 Rex Dieter 2015-01-10 13:16:58 EST
Re: comment #55

This bug (per it's title "provide a methiod to disable tracker") is precisely that, a feature request to implement exactly (and only) that.

Peripheral issues referenced (like privacy and information leaks) is a separate issue.  Feel free to open a new (separate) bug for that.
Comment 57 Thomas Cameron 2015-03-15 16:39:18 EDT
Really just a "me, too" comment here. Tracker is awful. I like to reset my user profile to "factory defaults" every once in a while by nuking the various dot files in my home directory. I mount my home directory via NFS, and some of my machines are RHEL6, some RHEL7, some Fedora.latest, heck, every once in a while I use RHEL5. So every once in a while, my dot files get wonky and I clean them up.

When this happens, it takes a half an hour for tracker to settle down after reindexing everything. This sucks. A lot. 

Please, give us a way to turn it off completely. I am currently using chmod -x against the executables, but that is a hackish solution and I don't like it. Give us a universal kill switch, please.
Comment 58 Konstantin Svist 2015-06-02 12:33:00 EDT
me2, kill it with fire!
Comment 59 Laszlo Ersek 2015-07-21 09:42:43 EDT
This anti-feature, this defect-by-design, is an abomination. Kill it already!

(At least I found <http://www.putorius.net/2014/12/disable-tracker-on-fedora-21-fedora-20.html>.)
Comment 60 Jean-François Fortin Tam 2015-07-21 16:43:22 EDT
For the record, I've had a surprisingly good experience with Nautilus+Tracker in Fedora 22: I don't even notice it's there, and search results are instantaneous. So if it continues to behave that way in the future, I might not mind as much anymore.
Comment 61 Igor Gnatenko 2015-07-21 16:49:08 EDT
(In reply to Laszlo Ersek from comment #59)
> This anti-feature, this defect-by-design, is an abomination. Kill it already!
> 
> (At least I found
> <http://www.putorius.net/2014/12/disable-tracker-on-fedora-21-fedora-20.
> html>.)
many ++

So, Closed as WONTFIX (I personally like it more than NOTABUG).
Comment 62 Gabor Garami 2015-07-23 08:14:27 EDT
Errm. Even if it can be disabled somehow, it does not solve the issue it is a unneccessary hard dependency of some packages. So I definitely do not see why you close it as WONTFIX. Being a hard dependency is a bug and I honestly hope you do not wanted close a bug with WONTFIX.

If it is really required to ship as a hard dependency, then please make it disabled by default to make it opt-in for users. Even if there is a way to get rid of this resource hog, this should not be a solution.
Comment 63 Igor Gnatenko 2015-07-23 09:20:55 EDT
tracker works only in GNOME (I mean starts). some applications will NOT works without tracker, for example GNOME Notes (bijiben), GNOME Music (gnome-music) and you will lost features in GNOME Files (nautilus).

So if you don't want to have tracker in system - just remove tracker, but you will know, some apps will not work. Because that apps included in Fedora Workstation we should support features done by tracker.
Comment 64 Thomas Cameron 2015-10-14 10:39:41 EDT
My home directories are also NFS mounted. I used to chmod the various tracker binaries so they're not executable, but then, when there's an update, my system loses its mind again and builds a mammoth ~/.cache/tracker directory.

This time (tracker-1.4.1-1.fc22.x86_64), I went into tracker-preferences, unchecked everything I could find, and cleared the indexes through the UI.

It seems to have worked. The tracker process immediately stopped beating up my system, and it has not bothered me yet (several weeks, maybe months). My ~/.cache/tracker directory is only about 4.2M. The tracker processes are running, but they don't seem to do anything.

I still think the dependency chain is broken, but at least this irritating app is no longer thrashing my NFS server.
Comment 65 Frank Ch. Eigler 2015-10-14 20:08:29 EDT
See bug #1271872 for Part IV, A New Hope.
Comment 66 Gerd v. Egidy 2015-10-20 16:56 EDT
Created attachment 1084926 [details]
script to disable tracker for all users from /etc/profile.d

Copy the attached script to /etc/profile.d/ and each time a user logs in, it will disable tracker for him.

This is a more automated and more easy distributable version of the solution I proposed in comment#22

I also updated it for Fedora 22.
Comment 67 Sergio Monteiro Basto 2016-01-01 18:59:52 EST
dnf remove tracker


seems that fix the problem , wtf with kde , I have to have tracker installed
Comment 68 Ian Donaldson 2016-01-01 19:37:12 EST
We use kde here exclusively and it doesn't seem to actually
require tracker, so doing this works for us:

rpm -e --nodeps tracker
Comment 69 Ian Donaldson 2016-01-01 19:37:51 EST
(using fc21, fc22)
Comment 70 Sergio Monteiro Basto 2016-01-02 11:11:03 EST
(In reply to Sergio Monteiro Basto from comment #67)
> dnf remove tracker
> 
> 
> seems that fix the problem , wtf with kde , I have to have tracker installed

Need set /etc/dnf/dnf.conf with 

    clean_requirements_on_remove=false

with clean_requirements_on_remove=true removes too many packages , this on F23
Comment 71 Thomas Cameron 2016-01-04 10:34:23 EST
You guys are making this waaaaaaay too hard. If you don't want tracker to run, then just run tracker-preferences and turn it off. This has worked for me for a couple of releases now. It's not hard. Takes a minute or two, and it sticks through updates.
Comment 72 Rex Dieter 2016-01-04 13:07:49 EST
That definitely counts as a method to disable tracker, enough to consider the matter resolved in my opinion, thanks.
Comment 73 Ian Donaldson 2016-01-04 19:01:42 EST
So you expect me to login to every one of my staff member's accounts
and set that option?    Surely you jest.

The solution proposed in Comment 66 attempts to automate this process,
but as the system administrator here I set the policies; I don't
want my staff to override that by accident or deliberately; thus I need
a system wide policy control on this, not just a user preference.

Removing tracker completely stops this for everybody, but as some
say this may impact GNOME, which luckily we don't use here.

The system-wide tweak proposed in Comment 41 may be more appropriate for some.
Comment 74 Fdor 2016-09-17 07:14:01 EDT
In bug 1271872 I have proposed to change the rpm dependency from "Requires"
to "Recommends". Take a look there.
Comment 75 Igor Gnatenko 2017-03-14 10:44:44 EDT
*** Bug 1432108 has been marked as a duplicate of this bug. ***
Comment 76 Debarshi Ray 2017-03-15 09:02:27 EDT
(In reply to Thomas Cameron from comment #71)
> You guys are making this waaaaaaay too hard. If you don't want tracker to
> run, then just run tracker-preferences and turn it off. This has worked for
> me for a couple of releases now. It's not hard. Takes a minute or two, and
> it sticks through updates.

Yes, that should work.

tracker-preferences might be a bit hidden away since it is not integrated with Settings, so another alternative is:
  Settings -> Search -> gear menu -> disable the locations

(In reply to Ian Donaldson from comment #73)
> So you expect me to login to every one of my staff member's accounts
> and set that option?    Surely you jest.

Like most settings in GNOME, the ones for tracker are backed by dconf. dconf offers a few features that's useful for administrating large deployments. See:
https://help.gnome.org/admin/system-admin-guide/stable/dconf.html.en
https://wiki.gnome.org/action/show/Projects/dconf/SystemAdministrators

In the future we expect administrators use something like Fleet Commander (https://github.com/fleet-commander) to manage settings across large installations.
Comment 77 Sergio Monteiro Basto 2017-03-15 10:47:35 EDT
I use kde and tracker starts by default , and try tracker everything like external disk, nfs files system ,
I don't  Settings -> Search -> gear menu -> disable the locations
Comment 78 Tomasz Kłoczko 2017-03-15 17:32:52 EDT
> Yes, that should work.

> tracker-preferences might be a bit hidden away since it is not integrated with
> Settings, so another alternative is:
> Settings -> Search -> gear menu -> disable the locations

Problem is that it doesn't work.
I have disabled all search settings with search off as well and still tracker processes are started during Gnome session initialization and they are eating IOs/CPU/memory.
Comment 79 Debarshi Ray 2017-03-16 14:54:10 EDT
(In reply to Tomasz Kłoczko from comment #78)
> > Yes, that should work.
> 
> > tracker-preferences might be a bit hidden away since it is not integrated with
> > Settings, so another alternative is:
> > Settings -> Search -> gear menu -> disable the locations
> 
> Problem is that it doesn't work.
> I have disabled all search settings with search off as well and still
> tracker processes are started during Gnome session initialization and they
> are eating IOs/CPU/memory.

You ignored my question in the duplicate bug (ie. bug 1432108). How much is it consuming? Is it enough to be a significant problem? Or are you complaining about a sleeping process in your process table?
Comment 80 Tomasz Kłoczko 2017-03-19 22:16:52 EDT
(In reply to Debarshi Ray from comment #79)
> You ignored my question in the duplicate bug (ie. bug 1432108). How much is
> it consuming? Is it enough to be a significant problem? Or are you
> complaining about a sleeping process in your process table?

It was enough IOs that I've started looking for what is consuming those IOs.
iotop in critical moment showed those tracker processes on top of the list.

I'm complaining about processes in RUNNING QUEUE which according to desktop settings (completely disabled all search settings) never should be started and never should plow across user home directory.
Comment 81 loopsysdev 2017-07-11 08:24 EDT
Created attachment 1296211 [details]
Puppet definition to disable autostart

Used to manage a few office machines. Based on this thread and <https://gist.github.com/najamelan/b44e943145b03e018229#x-gnome-autostart-enabled>. Usage for Fedora 25:

class tracker {
  tracker::disable_autostart {
    [
      '/etc/xdg/autostart/tracker-extract.desktop',
      '/etc/xdg/autostart/tracker-miner-apps.desktop',
      '/etc/xdg/autostart/tracker-miner-fs.desktop',
      '/etc/xdg/autostart/tracker-miner-rss.desktop',
      '/etc/xdg/autostart/tracker-miner-user-guides.desktop',
      '/etc/xdg/autostart/tracker-store.desktop',
    ]:
  }
}

Note You need to log in before you can comment on or make changes to this bug.