trackerd uses 100% cpu

Bug #239391 reported by Thomas N on 2008-06-12
This bug affects 9 people
Affects Status Importance Assigned to Milestone
tracker (Ubuntu)

Bug Description

Binary package hint: tracker

For a few days now trackerd has started to consume 100% CPU. I have two computers and I can see the same issue on both.

If I do "pause all indexing" nothing changes.

If I do a kill on trackerd nothing changes.

$ apt-cache policy tracker
  Installed: 0.6.6-0ubuntu3.8.04.1
  Candidate: 0.6.6-0ubuntu3.8.04.1
  Version table:
 *** 0.6.6-0ubuntu3.8.04.1 0
        500 hardy-proposed/main Packages
        100 /var/lib/dpkg/status
     0.6.6-0ubuntu3 0
        500 hardy/main Packages

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04.1

Confirmed. I just got this today. It doesn't respond to SIGTERM, only SIGKILL (i.e., "kill -9").

$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04
$ apt-cache policy tracker
  Installed: 0.6.6-0ubuntu3.8.04.1
  Candidate: 0.6.6-0ubuntu3.8.04.1
  Version table:
 *** 0.6.6-0ubuntu3.8.04.1 0
        500 hardy-updates/main Packages
        100 /var/lib/dpkg/status
     0.6.6-0ubuntu3 0
        500 hardy/main Packages

Changed in tracker:
status: New → Confirmed
Alexander Rødseth (alexanro) wrote :

Same here. Tracker does not respect the "pause" option. Also, after it has indexed the files, it starts indexing files again when the computer is restarted. In general, trackerd does not respect the user at all.

Mark Garrow (scunizi) wrote :

I upgraded Hardy to Intrepid with a fresh install but retaining my /home on a separate drive/partition. Trackerd ran correctly (as far as I could tell) on Hardy, but consistently eats 50%+ of my CPU on Intrepid. I have to turn it off either by killing it or using System>Preferences>Search and Indexing and turning it off there.. It doesn't respect the "pause" function.

It does not exhibit this behavoir on a fresh install of Ibex in a Vbox install.

My system is xfx geforce 8200 MB, 4 gigs of ram,

$ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

 apt-cache policy tracker
  Installed: 0.6.6-1ubuntu5
  Candidate: 0.6.6-1ubuntu5
  Version table:
 *** 0.6.6-1ubuntu5 0
        500 intrepid/main Packages
        100 /var/lib/dpkg/status

Any other info you might need just let me know, and also the appropriate way to retrieve the needed info.

Mark Garrow (scunizi) wrote :

As an additional test concerning another bug I filed, I created a new user. Tracker does NOT exhibit the same behavior with the new user at all.. it indexed the system in 45 sec. with little cpu usage.

So that begs the question .... how do I fix the primary user?

Mark Garrow (scunizi) wrote :

Since a new user doesn't suffer from this behaviour, how do I fix my primary user so the behaviour ends?

TJ (tj) wrote :

I can reproduce this where Evolution email is being indexed. With debug logging enabled I see:

top - 10:00:57 up 2:41, 4 users, load average: 1.55, 1.30, 1.21
Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie
Cpu0 : 3.3%us, 1.0%sy, 74.8%ni, 19.6%id, 0.0%wa, 0.0%hi, 1.3%si, 0.0%st
Cpu1 : 3.3%us, 0.7%sy, 22.6%ni, 73.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2061880k total, 2033472k used, 28408k free, 364756k buffers
Swap: 4000176k total, 0k used, 4000176k free, 501588k cached

10127 tj 39 19 138m 12m 2668 S 99 0.6 146:20.61 trackerd
 9926 root 20 0 195m 59m 18m S 2 2.9 3:02.17 Xorg
10051 tj 20 0 223m 16m 3852 S 1 0.8 0:25.72 pulseaudio

With debug logging (Verbosity=3) enabled the 100% CPU usage is caused by:

Scanning summary file /home/tj/.evolution/mail/imap/ Lists/subfolders/video4linux/summary for junk
summary.version = 13
summary.flags = 1
summary.nextuid = 1
summary.time = 0
summary.count = 5265
summary.Unread = 50
summary.deleted = 5173
summary.junk = 0
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=9
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=13
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=28
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=30
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=48
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=50
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=54
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=55
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=56
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=57

... and it goes on and on.

Changed in tracker:
assignee: nobody → intuitivenipple
TJ (tj) wrote :

Upstream have applied the patch to fix this.

Changed in tracker (Ubuntu):
assignee: intuitivenipple → nobody
Dave Gilbert (ubuntu-treblig) wrote :

I'm seeing this on current Jaunty beta (with 0.6.91-1ubuntu1 tracker); it's using 100% cpu writing loads of:

02 Apr 2009, 19:09:39: Tracker-Warning **: Could not store word 'info_loc': with fatal error
02 Apr 2009, 19:09:39: Tracker-Warning **: Could not store word 'vt1724_reg_control': with fatal error

type message into ~/.local/share/tracker/tracker-indexer.log

Even more annoying is the fact 'enable indexing' is off in the 'Tracker preferences' dialogue.


Tiefflieger (tiefflieger) wrote :

I have the same issue like Dave, but at my pc it's using 50% CPU - maybe because it's a double-core?

Bryan McLellan (btm) wrote :

The "could not store word" errors at least are Bug 346912.

ThomasNovin, do you see these errors in "~/.local/share/tracker/tracker-indexer.log" as well?

bgruber (bgruber) wrote :

I don't see that in the indexer log. In fact, the indexer is not running when this happens. I can also confirm that (for me anyhow) this is the same as Debian bug #521380; it seems like trackerd is in a tight polling loop for some reason.

Changed in tracker:
status: Unknown → New
Mark Grandi (markgrandi) wrote :

today, i decided to enable tracker and let it index my home folder. after coming back, my computer was UNUSABLE because trackerd or tracker-indexer was using up so much of my cpu, it took about 5 minutes just for my computer to drop to a terminal mode, type in my login information, and type sudo restart.

This is a pretty bad bug...

AndyOsi (andres-osinski) wrote :

Confirmed. It's impossible to use Tracker because of this. This has been happening since the release of Jaunty.

mdmcginn (mcweb) wrote :

I've never been able to use Tracker. Indexing fails, searches bring no results, high CPU usage even when not idle and with NICE 19, etc.

  Installed: 0.6.95-1ubuntu3
  Candidate: 0.6.95-1ubuntu3
  Version table:
 *** 0.6.95-1ubuntu3 0
        500 karmic/main Packages
        100 /var/lib/dpkg/status

Mark Grandi (markgrandi) wrote :

How very convenient, i just installed tracker yesterday on Karmic to see if they had fixed the bug. whoops! that was too generous of me to think that given 6 months this bug would of at least been confirmed or fixed. I guess not. And given the fact that tracker is not installed by default on ubuntu anymore I guess the ubuntu developers thought the same way. (If i sound miffed, its because the fact that its almost impossible to get a decent search framework/program on linux , tracker is the best one, but then stupid things like this just make it completely unusable)

Jesse Kahtava (jesse-kahtava) wrote :

I've been having this problem as well and found this yesterday:
It's for Fedora, but trackerd seems to be having this issue one other distros as well. I tried the suggested fix yesterday and trackerd hasn't started going crazy since. I'll update if it still happens.

Olivier Bilodeau (plaxx) wrote :

I was about to report my problem upstream (100% cpu usage) and I've found this page:

I've followed Anita's advice:

and I've watched the re-indexing using:
tracker-status -fd

and it never went back to 100% cpu. I've logged in / logged out and I put my laptop to sleep, no problem.

Upgrading ubuntu certainly was the cause but deleting the cache and re-creating it from scratch fixed it for me. Maybe a distro upgrade should remove the cache?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.