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.
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
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.
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.
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.
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).
This type of tool doesn't fit well in some environments. There must be a way to globally disable / remove this package.
This seems to work pretty well for me. YMMV. rpm -e --nodeps tracker brasero brasero-nautilus
(In reply to comment #7) > rpm -e --nodeps tracker brasero brasero-nautilus Why is it necessary or desirable to remove brasero?
Possibly not necessary; just less lines of complaint from 'yum check', and I don't need it.
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)
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.
(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.
(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.
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 ...
There still doesn't appear to be a reasonable way to disable tracker in Fedora 17.
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.
(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
And removing tracker seems to cause "klipper" to fail :-(
(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.
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.
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.
> 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.
(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).
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
FYI, bug 771601 is addressing this for KDE and Xfce.
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.
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.
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
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)
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
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.
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.
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.
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?
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.
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.
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
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 ?
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 !!!
sixpack13: This won't persist. The next time there is an update to the package the permissions will change back.
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
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
Changing ~/.profile as given Comment 24 worked for me. No more tracker - bliss. I'm running Debian 7 and openbox.
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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?
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.
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?
still a problem in fedora 21
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.
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.
still a problem in fedora 21 -> changing version
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
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
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.
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.
me2, kill it with fire!
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>.)
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.
(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).
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.
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.
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.
See bug #1271872 for Part IV, A New Hope.
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.
dnf remove tracker seems that fix the problem , wtf with kde , I have to have tracker installed
We use kde here exclusively and it doesn't seem to actually require tracker, so doing this works for us: rpm -e --nodeps tracker
(using fc21, fc22)
(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
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.
That definitely counts as a method to disable tracker, enough to consider the matter resolved in my opinion, thanks.
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.
In bug 1271872 I have proposed to change the rpm dependency from "Requires" to "Recommends". Take a look there.
*** Bug 1432108 has been marked as a duplicate of this bug. ***
(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.
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
> 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.
(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?
(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.
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', ]: } }
(In reply to Jeff Bastian from comment #1) > 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 Just to note that this would be lovely solution, but it doesn't work. I have here matej@mitmanek: ~$ ls -1 .config/autostart/ tracker-extract.desktop tracker-miner-apps.desktop tracker-miner-flickr.desktop tracker-miner-fs.desktop tracker-miner-user-guides.desktop tracker-store.desktop matej@mitmanek: ~$ all with this content, but I still have to kill /usr/libexec/tracker-extract taking over one of my cores all the time. Having tracker-1.10.5-6.el7.x86_64 on RHEL-7.
rpm -e tracker brasero --nodeps is the more efecient way , but break nautilus nautilus nautilus: error while loading shared libraries: libtracker-sparql-1.0.so.0: cannot open shared object file: No such file or directory
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.
after: dnf install tracker-preferences
tracker-preferences no longer exists (at least in fedora 27)
I confirm that tracker-preferences is only available on Fedora 26 dnf repoquery -f /usr/bin/tracker-preferences -q tracker-preferences-0:1.12.1-1.fc26.x86_64 tracker-preferences-0:1.12.4-1.fc26.x86_64 dnf repoquery --disablerepo='*' --enablerepo=rawhide -f /usr/bin/tracker-preferences -q (none results)
(In reply to Matěj Cepl from comment #82) > (In reply to Jeff Bastian from comment #1) > Just to note that this would be lovely solution, but it doesn't work. I have > here To be fair, my suggestion in comment 1 is approaching 7 years old now. :-)
(In reply to Jeff Bastian from comment #88) > (In reply to Matěj Cepl from comment #82) > > (In reply to Jeff Bastian from comment #1) > > Just to note that this would be lovely solution, but it doesn't work. I have > > here > > To be fair, my suggestion in comment 1 is approaching 7 years old now. :-) I know, but I haven't understood why a good interface should be eliminated, except Gnome is really CADT driven (https://www.jwz.org/blog/2003/02/the-cadt-model/). Anyway, could somebody suggest some other way how to stop tracker (I don't like the suggestion in comment 24, do you)?
This is indeed a completely ridiculous issue. Over those last 7 years, there have been numerous efforts to stop tracker from behaving madly, yet unfortunately, as the gnome project has progressed and changed, many of those workarounds don't work anymore. I currently resort to the lowest level of defense and do this: sudo chmod -x /usr/bin/tracker && chattr +i /usr/bin/tracker sudo chmod -x /usr/lib/tracker/tracker-store && chattr +i /usr/lib/tracker/tracker-store
Just a friendly reminder on expected behavior: https://getfedora.org/code-of-conduct.html.en I see an increase in negative-toned comments here, which are not helpful or constructive. Please keep that in mind.
(In reply to Matěj Cepl from comment #82) > all with this content, but I still have to kill /usr/libexec/tracker-extract > taking over one of my cores all the time. If it is frequently taking over one of your cores, then it will be very interesting to see a stack trace before you kill it: $ gstack $(pidof tracker-extract) Run it a few times to ensure that you really catch it in the act.
(In reply to Rex Dieter from comment #86) > tracker-preferences no longer exists (at least in fedora 27) Yeah, tracker-preferences doesn't exist anymore but you still have the settings: https://git.gnome.org/browse/tracker/commit/?id=d4a8d6e45e991758440276b4ca3ad6e821dfdab2
I'm not currently running Gnome (though I still have it installed), I'm running Cinnamon. How do I access "Settings -> Search"? gnome-control-center comes up blank window, perhaps because I'm not under gnome? I have software I don't want to close now, I'd rather not log off into another desktop to just disable its software... (Yes this is entitled of me, just saying it's not very discoverable route if you're running another desktop...) `tracker-preferences` no longer exists. `tracker status`, `tracker daemon kill` etc. are useful but sound like something that will affect current session only? Tried dconf-editor, but the settings mentioned above $ gsettings get org.freedesktop.Tracker.Miner.Files crawling-interval $ gsettings get org.freedesktop.Tracker.Miner.Files enable-monitors no longer exist. Could anyone say how exactly to disable with dconf now (F28)? I tried uninstalling `tracker-miners`, which didn't have as much collateral packages as `tracker`, only gnome-documents. That helped some, but then I saw tracker-miner-fs still one of top processes... I'm switching desktops about once a year, when previous one becomes too unstable for me. Tracker has been a consistent sore for last several years I'm on fedora (since F24?). I thought I'd already banished it, maybe twice :-) So +1 to `rpm -e --nodeps tracker` but I still want a solution that will persist. Please make dependencies on tracker "recommend" and let us "dnf remove" (without uninstalling a third of Gnome) it pretty please? Because "dnf remove" is the most *discoverable* way to get rid of software you don't need.
Hi, To add to this - using F28 and KDE - above does not work - no tracker-preferences. tracker-extract takes a lot of resource. There does not seem to be a way to disable, or remove without causing issues with other packages. Given that it persistently takes resource, up to 100% of one core sometimes, then i see this program as a bug/malware. Any designed resolution as part of F28 would be grateful. Regards, Shadders.
Hi, Under F28 I have the same problem. When I run Gnome session then tracker is alive (although I have Search off from Gnome settings), but it behaves decently (perhaps because it is switched "off"). When I'm using Cinnamon session, then the tracker (tracker-store) is constantly active and it takes huge amount of memory (during few hours of running the memory consumption is 6-8 GB) and CPUs are heavily loaded. When I run command tracker status (regardless the session - Gnome or Cinnamon), the most frequent output is "Data is still being indexed: Estimated less than one second left" or sometimes "All data miners are idle, indexing complete". Tracker database size is ~300 MB. If I kill the tracker-store then it reactivates in some time during the same session. There should be decent way to disable Tracker (or at least force it to do nothing) - especially if I newer use it anyway.
Tracker is currently making my F28 machine unusable on a daily basis, due to its unbridled resource consumption. It's at the point now where I either need a way to remove or disable tracker, or I need to stop using Fedora. I realise I'm late to the party, but would appreciate the answer to a couple of questions: 1) Since this bug is closed, is there another one with the same goal which I should be following instead? 2) Is there an "official" workaround available, or do we need to resort to the heavy-handed approaches above (like comment #90)?
I suggest opening a new bug against f27/f28 if there does not currently exist a practical method of turning it off.
(In reply to Frank Ch. Eigler from comment #98) > I suggest opening a new bug against f27/f28 if there does not currently > exist a practical method of turning it off. Bug #1613103
(In reply to Frank Ch. Eigler from comment #98) > I suggest opening a new bug against f27/f28 if there does not currently > exist a practical method of turning it off. This is an excellent idea
This bug was originally filed against rawhide, almost 7 years ago. And no matter if this bug has been closed multiple times, tracker's behaviour is still as troublesome for some people as it has been since the bug has been reported. What's the exact point of having this bug closed and opening another one for f28 (which will sooner or later get autoclosed because EOL of f28)? The bug/issue/problem still exists in rawhide, too, like it always has ...
This solution has been working for me for all 7 years: Add this to the end of ~/.bashrc # Kill with fire. killall -9 -r tracker-.* >& /dev/null
I've masked it in systemd: > systemctl --user mask tracker-store.service > systemctl --user status tracker-store.service ● tracker-store.service Loaded: masked (/dev/null; masked) Active: inactive (dead) I don't really know if this is a recommendable way to make it shut up. Moreover: each user has to do it. Best would be to make it uninstallable I think. B.
In Gnome 3, open Settings, then choose Search, and in the upper right side of the window, toggle search off. Tracker will still run, but it doesn't index anything and is no longer a resource hog.
The funny thing is that although I have switched search off from the Gnome settings the indexing still happens.
I know that tracker still runs, but if you turn off search it *should* not index anything. Is it still doing the full index? Maybe if you turn on search, then toggle everything that it can search to "off?" Sorry, I'm in XFCE right now and can't test this on my real home directory. I tested in a VM and it didn't appear that it actually indexed anything. I'm sorry if I'm wrong.
Now when I switched tracking on and toggled everything off what the Tracker can index it indeed stopped indexing (at least for now). Also I got immediately ABRT notification "tracker quit unexpectedly" but actually Tracker runs in the background