Tracker index corruption (was Tracker does not stop indexing)

Even though it's a "me too"-post:
I'm having the same problem, also the trackerd.log file contained some remark that the sqlite db had some problem with virtual tables. As soon as I solve some other problems, I'll post some logs...

Here is my config file.

Sorry for the previous post. I forgot to attach the file. Note that I turned off smart pausing in order to test this issue.

This is a QDBM problem. We are replacing this database in the coming months. For now, we are not sure why it does this but it usually happens when your index is corrupt.

Is there a temporary solution? Which files should I delete?

if you use the applet to reindex, that should fix it. The equivalent command is $prefix/libexec/trackerd -r

Reindexing does not work. Indeed immediately after the "reindex" command he tracker-indexer.log file shows only "transaction ok"-type messages, but after 30 min or something, the buggy behaviour (trackerd ~ 100% CPU, "could not store word", and the non-counting-count (403 of 45000 forever)) is back. The logfiles are full of error messages but the moment, the error startet has obviously been overwritten... Should I do something specific to help?

Same here. It takes only a 1-2 minutes for the error logs to get flooded by those messages. Tracker-extract even crashed after I started reindexing (bug report submitted, see https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/347609). Is there a way to purge this corruption before the new database comes in use?

This should be fixed in TRUNK. A reindex is needed when it happens, you can use tracker-processes -r to do that, note it will kill all processes and databases. If you don't have that command, you need a newer version :)

Also, if trackerd -r didn't work, it is because you still had tracker processes running which were using the database or writing to it.

I just updated to 0.6.92-1ubuntu1 and the problem persists.

- indexing progress stops after 702 files (in my case)
- tracker-indexer.log gets spammed with entries as described above
- trackerd.log shows the following:

bernhard@Magnesium:~/.local/share/tracker$ tailf trackerd.log
04 Apr 2009, 17:00:51: Tracker-Warning **: Error loading query:'sqlite-fulltext.sql' #0, Cannot use virtual tables in shared-cache mode
04 Apr 2009, 17:00:59: Tracker-Warning **: Error loading query:'sqlite-fulltext.sql' #0, Cannot use virtual tables in shared-cache mode

By the way, I don't have a "tracker-processes" command in my path (current jaunty beta) - should there be one? I'll gladly use a newer version if it just gets this regression fixed...

Not having tracker-processes is a packaging bug, it is available from 0.6.92 onwards, but it wasn't included. There is a bug about it here somewhere :)

Those two warnings above are fine to ignore.

The logs you show above is with QDBM failing to index a word. We are not entirely sure why this happens and a reindex is the only way to fix it. If it keeps happening, we would like to know if it is ONE file which causes this or something else? This should be resolved once we move to SQLite FTS (i.e. remove QDBM). That won't be until 0.7.x though.

QDBM failure is likely to be a result of not using fsync in conjunction with one of the following

1) use of Ext4. Not a problem on ext3 as an sqlite fsync would automatically fsync QDBM
2) Use of suspend/resume while tracker is indexing. This has caused tracker to corrupt QDBM index in the past. Not sure why this is so but does not affect sqlite

I agree that sqlite FTS should solve above two cases as Ive seen no reports of the sqlite db getting corrupted

Actually, we should probably detect such a case and pause indexing for the shutdown as soon as we know the process has started.

2009/4/6 Martyn Russell <email address hidden>:
> Not having tracker-processes is a packaging bug, it is available from
> 0.6.92 onwards, but it wasn't included. There is a bug about it here
> somewhere :)
>
> Those two warnings above are fine to ignore.
>
> The logs you show above is with QDBM failing to index a word. We are not
> entirely sure why this happens and a reindex is the only way to fix it.
> If it keeps happening, we would like to know if it is ONE file which
> causes this or something else? This should be resolved once we move to
> SQLite FTS (i.e. remove QDBM). That won't be until 0.7.x though.
>

I indeed forgot to include tracker-processes in the Debian package.

I've split the command line utilities into a separate, optional
tracker-utils package. It currently contains
/usr/bin/tracker-stats
/usr/bin/tracker-search
/usr/bin/tracker-tag
/usr/bin/tracker-meta-folder
/usr/bin/tracker-services
/usr/bin/tracker-info
/usr/bin/tracker-status
/usr/bin/tracker-files
/usr/bin/tracker-unique
/usr/bin/tracker-query

ie, binaries that are not strictly required if you are using graphical
frontends.

Martyn, I guess this new binary should be added to the binary package
tracker though, as trackerd relies on it, right?

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael, it looks like this new utility is just for managing tracker processes, and isn't required for the daemon. I think for consistency that it should go in tracker-utils.

Michael, Chris, yes, it should be added to tracker-utils. It also allows the user to kill/terminate all tracker processes and which is most useful, reset all tracker databases after killing processes. The tracker-processes -r command is now what we suggest to use when people have corruption in their databases and they need to reindex everything (if they don't do it from the applet or some graphical interface).

tracker-processes has now been added to tracker-utils in Ubuntu

This bug is also rendering my system (almost) unusable. I have a Core Duo CPU, so one of my core is still free for user tasks, but the usage on the other core is 100%.

I've tried deleting the database / cache / logs but nothing works, the tracker will run into the problem again, and again, and again. This is most definitely related to the amount of documents/words being indexed since I have ~15Gb worth of indexable docs.

This started to happen once I upgraded to Jaunty, latest devel version. Hopefully a fix will be forthcoming before Jaunty is going final.

There is a 2gb file size limit on qdbm so you might be experiencing that

Sqlite FTS has no such limit so will cure this problem in tracker 0.7.x

The new version in Jaunty detects corruption and gives you the option of re-indexing. This should stop the problem where tracker uses 100% CPU (so I've adjusted the title now) but obviously doesn't stop the corruption, so I'll keep this report open.

Chris,

Now I am getting a loop of:

  Tracker
  There was an error while performing indexing:

  Index corrupted

dialogs. Cancel it, and it comes back. Click to index all contents, and it comes back. Click OK, and ...

So choosing to re-index did not appear to help.

I've run tracker-processes -r, so we'll see if that helps.

Could someone please clarify the ext4 issue?

- Does tracker 0.6.9x generally have to get corrupted DBs due to a QDBM-ext4-issue?
- Is there a different solution other than reformatting to ext3 or xyz-fs or waiting for tracker 0.7.x?
- Specifically: Would it be viable to come up with some special QDBM-build for ext4-users - or would something like that be too slow due to heavy syncing?
- Finally: Could tracker find out (at install/configuration time) if its DBs are sitting in an ext4-minefield and throw up a warning dialogue or something?

I have also seen the looping problem Noel Bergman reports above.

 dpkg -l | grep tracker
ii libdeskbar-tracker 0.6.93-0ubuntu1 metadata database, indexer and search tool - deskbar-ap
ii libtracker-gtk0 0.6.93-0ubuntu1 GTK+ widgets for apps that use tracker
ii libtrackerclient0 0.6.93-0ubuntu1 metadata database, indexer and search tool - library
ii tracker 0.6.93-0ubuntu1 metadata database, indexer and search tool
ii tracker-search-tool 0.6.93-0ubuntu1 metadata database, indexer and search tool - GNOME fron
ii tracker-utils 0.6.93-0ubuntu1 metadata database, indexer and search tool - commandlin

Jane Silber (dupe in bug 361021) just confirmed that she is still suffering from the neverending 100% CPU issue with the latest tracker (0.6.93-0ubuntu1), so it seems that contrary to comment 21 this is not fixed yet?

As discussed in #ubuntu-desktop, could we drop the broken quasi-notification-dialog and just do the reindexing if index corruption is detected? there's no other sane answer anyway, is there?

Martin: In case you're not aware, I think the notification dialog issue has been addressed here:

https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/361205

fyi: problem so far occured here on all upgrades to current release candidate (from 8.10 or 9.04 alpha/betas), but not on clean/new installs. Rgds, Dani

I can confirm this problem on a completely clean, brand new install of the 9.04 beta.

I can confirm the bug cannot be solved by reindexing, only by removing the contents of ~/.cache/tracker, and of ~./.local/share/tracker/data. After reindexing then, everything is fine (I'm using version 0.6.93-0ubuntu1).

Maybe a more radical solution should be used by Tracker when the DB is corrupt, especially to help people that are upgrading from previous Jaunty states.

Confirming still an issue with my Jaunty RC. I get pop ups saying my index is corrupted, but whatever I click the message keeps popping up.

Experiencing this both on i386 and PPC, with systems updated to today.

I can confirm its still an issue.

My ~/.local/share/tracker/tracker-indexer.log is growing at a rate of ~300 KB/s with the message repeated over:

22 Apr 2009, 14:14:04: Tracker-Warning **: Could not store word 'css': with fatal error

All other logs are empty. Will try solutions suggested by users.

I can confirm this problem happens after hibernation & suspend. I'm also using ReiserFS.

The importance of this bug should be very high - it will impact many users that have above a few GBs of indexable data. It might even have "blocker" potential. Currently I'm learning to live without indexing until this bug is fixed.

A possible workaround [needs the tracker-utils package - sudo aptitude install tracker-utils] is to reset databases and clear caches:
tracker-processes -r

If the workaround is ineffective you might want to uninstall the package:
sudo aptitude remove tracker

Tracker is just unusable with Jaunty/ext4 from an upgrade.
I removed it, and installed beagle : indexing is fine, longer but system
doesn't slow down like tracker... and it doesn't hang.

I agree with the last post, this bug have to be fixed before the final
release.

On Wed, Apr 22, 2009 at 2:54 AM, Ciprian Enache <email address hidden>wrote:

> The importance of this bug should be very high - it will impact many
> users that have above a few GBs of indexable data. It might even have
> "blocker" potential. Currently I'm learning to live without indexing
> until this bug is fixed.
>
> A possible workaround [needs the tracker-utils package - sudo aptitude
> install tracker-utils] is to reset databases and clear caches:
> tracker-processes -r
>
> If the workaround is ineffective you might want to uninstall the package:
> sudo aptitude remove tracker
>
> --
> Tracker index corruption (was Tracker does not stop indexing)
> https://bugs.launchpad.net/bugs/346912
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Meta-tracker: New
> Status in “tracker” source package in Ubuntu: Triaged
> Status in tracker in Ubuntu Jaunty: Triaged
>
> Bug description:
> I recently realized that tracker does not always give me the search results
> I expected, meaning that it does not find documents containing certain
> words. A quick look through the indexer preferences, I doubled the "maximal
> amount of text to index" and "maximum number of unique words to index".
> After doing so, the tracker does not stop indexing. The information message
> when I hover over the tracker icons says:
>
> Tracker: Indexing
> Done: 883 of 22296
> Estimated: 33 minutes ...
> Elapsed: 01 minute ...
>
> This message hasn't changed for about a day, and the indexing continues.
> One of my log files is continuously flooded with the following messages:
>
> nasko@serre:~/.local/share/tracker$ tail -n20 tracker-indexer.log
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'previous':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'troubl':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
> 'preprocessor': with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
> 'ac_abs_top_builddir': with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'detail':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'call':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'paramet':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'offshoot':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'with_gcc':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'honor':
> with fatal error
>
>
> I would like to have tracker index my files more fully, and yet have it do
> that in a normal manner. Is there a way to prevent this problem?
>

This bug will not be fixed before final release. Fixing it requires significant changes in Tracker, which are currently happening upstream. You can't delay an entire release for that.

Jaunty does not install tracker by default, thus fixing this in an SRU
is perfectly acceptable.

Have you all tried my solution:
- remove the contents of ~/.cache/tracker and of ~./.local/share/tracker/data
- reindex

Chris: as far as I understand the situation, this bug only affects people who upgraded to Jaunty somewhere are the beta. Is that true?

Milan, I can confirm that solution works. I am running the Jaunty beta, but I did not upgrade to it (completely fresh install on a brand new hard drive).

I can confirm that bug on the final 9.04 release updating from 8.10

provided solution:
- remove the contents of ~/.cache/tracker and of ~./.local/share/tracker/data
- reindex
didn't work.

aptitude install tracker-utils
tracker-processes -r

seems to work, but system is slower than before.

I upgraded to Jaunty (final) and after a couple hours began seeing persistent dialogs saying "There was an error while performing indexing: Index corrupted". (Same as many other reporters. No such problem on the fresh install on my desktop.)

I tried killing tracker, removing ~/.cache/tracker, and logging out and in. Tracker indexed all day yesterday without any of these dialogs (although my system was extremely slow) but this morning after suspending and resuming the problem came back.

I have a very long ~/.local/share/tracker/tracker-indexer.log that repeats "[timestamp]: Tracker-Warning **: Could not store word 'audibl': with fatal error" around 78,000 times and adds about 1,000 of the same message per second.

(I haven't tried deleting ~/.local/share/tracker/data as well--I'd try again but I'm not sure I can afford to have my system crawl to a halt for another day.)

I had the same problem on both of my systems, I upgraded both from Intrepid to Jaunty Final.
The solution:
- remove the contents of ~/.cache/tracker and of ~./.local/share/tracker/data
- tracker-processes -r
- restart trackerd (in a shell with -v 2 to check)
- let the system index over night
seems to have worked for me, indexing stopped and the last tracker-indexer.log shows a different error several hours ago...

A good number people, including me, have encountered this problem after upgrading to Jaunty. It makes the system quite unusable and its priority should be high.

I'm sorry for a bad english. I upgraded to Jaunty and have a same problem with index tracker.

My solution: purge the tracker data (if you don't know how, see above) and disable tracker (System->Preferences->Search and Indexing, clear Enable Indexing). Personally, I consider the capability a waste of time and space. Sorry, Jamie -- that is not a dig at your tracker; on every OS that has offered the option, I've always turned it off.

What I have not yet found is where tracker.cfg gets initialized from, so that new accounts don't start with it enabled.

@Noel: you can disable tracker for new accounts deleting the corresponding files in /etc/xdg/autostart.
However, this isn't related to this bug, so please help fixing it or at least avoid criticizing tracker; there are better places to do that.

No need to even do that. Tracker is disabled by default in Ubuntu, so you have to explicitly enable it in the preferences. This is true even for new users.

I can't restart tracker. If I disable and re-enable indexing in System->Preferences->Search and Indexing that doesn't do anything. And I don't have any "trackerd" executable on my system.

I started a discussion about this bug here:

http://ubuntuforums.org/showthread.php?p=7149477#post7149477

I hope that is helpful. I am a fairly simple end user, and I am not very familiar with the proper way to resolve bugs. I had lots of stupid questions with which I did not want to junk up this bug list.

Thank you all for working to resolve this bug. I use Ubuntu both for my work as a lawyer and in creating a documentary movie called the Digital Tipping Point, so I get a lot of good use out of Ubuntu. I am very grateful to have such fine software at no cost.

@Matteo: I was not criticizing tracker -- that I am trying to wort around this bug by purging the files and disabling the feature. And I made an explicit point of saying to Jamie -- you know, the author -- that my turning off the feature was *not* a criticism of his code. I just don't use or want the feature.

@Chris: if that's the case, then why have I had to turn it off on multiple installs? Was it on by default in the past, and that's a carry over? Moreover, In fact, why do I have:

  $ ps auxwww | grep track
  noel 4432 0.0 0.0 166552 3548 ? S 03:43 0:00 tracker-applet
  noel 4449 0.0 0.2 233152 9012 ? SN 03:43 0:00 /usr/lib/tracker/trackerd

and

  $ ls -l .cache/tracker/
  total 11344
  -rw-r--r-- 1 noel noel 1 2009-04-25 13:01 db-version.txt
  -rw-r--r-- 1 noel noel 1 2009-04-25 17:39 email-contents.db
  -rw-r--r-- 1 noel noel 3072 2009-04-25 17:39 email-fulltext.db
  -rw-r--r-- 1 noel noel 2359292 2009-04-26 03:48 email-index.db
  -rw-r--r-- 1 noel noel 34816 2009-04-25 17:39 email-meta.db
  -rw-r--r-- 1 noel noel 1 2009-04-25 17:39 file-contents.db
  -rw-r--r-- 1 noel noel 1069056 2009-04-26 03:43 file-fulltext.db
  -rw-r--r-- 1 noel noel 3563408 2009-04-26 03:48 file-index.db
  -rw-r--r-- 1 noel noel 4543488 2009-04-26 03:43 file-meta.db

  $ ls -l .local/share/tracker/data/
  total 88
  -rw-r--r-- 1 noel noel 84992 2009-04-26 03:43 common.db

if I have indexing disabled on the general tab? Do I also have to turn it off on the files and e-mail tabs, too? What does it take, short of an un-installing, to permanently kill this thing?

A few informations to stop these scared comments: :-)
- unchecking 'Enable indexing' in System->Preferences->Search & indexing should be sufficient to stop trackerd, at least after restarting your session if it's hanging

- you can prevent trackerd from starting by going to System->Preferences->Startup Applications, and unchecking the Tracker daemon

- you can always stop trackerd using Alt+F2 and then typing 'killall trackerd', or 'killall trackerd -9' if it's not quitting

- you can completely remove Tracker from your system by removing the tracker package, without any risk for your system

- Tracker was actually installed by default in previous versions, which explains why it may be installed in your box without you doing anything for that. But note that it has always been *disabled* by default.

- there is no 'trackerd' executable in your path, it's in /usr/lib/tracker/trackerd since it's not meant to be started manually

But apart from that, Tracker is a great tool! And, see, it's not so malicious than you may think...

Tracker bugged out for me too. Kept saying the index was corrupted and the pop-up box came up over and over, regardless of the option selected. Have tried the manual remove as above:

- remove the contents of ~/.cache/tracker and of ~./.local/share/tracker/data

Perhaps this should be an option on the popup?

@Milan "But note that it has always been *disabled* by default." - That I don't understand.

Yesterday I updated my Dell Latitude to Jaunty (came orig. with 7.10) and got the tracker error described above. I surely never intentionally activated indexing - I just don't know what it does. But it is active now ...

I also have the indexing problem. It is very hard to rid the desktop of the error message no matter what option I choose.

Next, my Tracker has been un-checked as suggested above by Milan, however, should we also un-check the Tracker Applet next to the Tracker?

My system is an Intel Core 2 Quad at 2.40 GHz.

Will check back to see if another solution should be considered. I'm not very savvy on all this but willing to help whatever I can.
Thanks Folks,
Moses

...So? Is there going to be a hot fix that kill trackerd, rm -rf all of the user files, and then reindexes?

My boss is pretty darn angry with this issue, and he think every other program is at fault as well. Suddenly his machine is extremely slow.

Why don't you push out a work around through the update system? There must be many people experiencing this.

Odin - see bug 361205. Perhaps you could try out the package in jaunty-proposed there and provide some information requested in that bug report.

It seems to work on 2 computers I saw with this trouble using the package in jaunty-proposed.

I would humbly submit that this bug priority should be raised to High, if not Critical.

a) One of the bugs that was merged into this one had a priority of high.
b) Medium status is not preferred, see https://dev.launchpad.net/BugTriage
c) Most importantly, this bug keeps a large number of users from completing crucial tasks (ie, using their system).

That actually seems a potential description of "critical", but since there's no data loss, and it may not be universal, and there may be workarounds, I can see that being bumped down to High. I cannot see why Medium should be used, though.

Medium is the correct priority for this (definately not critical - for that, the bug would need to make a large proportion of users machines unusable with no workaround. There is clearly a workaround here). Tracker is not enabled by default and you can easily disable it again if you're experiencing this bug.

Thomas - the issue about the repeated notifications, and inability to recover from the index corruption via reindexing is covered by a separate bug report (bug 361205), which is already high priority and I'm working on fixing that.

The actual corruption (this bug here) is most likely going to be wontfix for Jaunty, as it requires significant changes in tracker.

I upgraded from Intrepid and had this issue. I did what Bryan McLellan suggested in <a href="https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/361560/comments/30">bug 361560</a>:

  sudo apt-get install tracker-utils
  tracker-processes -r # --hard-reset

and ran
  /usr/lib/tracker/trackerd &
  tracker-applet &

Everything seems to be fine now.

Ah, thanks for the correction, and for your work on this. Sorry if I added
to any confusion.

On Fri, May 8, 2009 at 4:24 PM, Chris Coulson
<email address hidden>wrote:

> Thomas - the issue about the repeated notifications, and inability to
> recover from the index corruption via reindexing is covered by a
> separate bug report (bug 361205), which is already high priority and I'm
> working on fixing that.
>
> The actual corruption (this bug here) is most likely going to be wontfix
> for Jaunty, as it requires significant changes in tracker.
>
> --
> Tracker index corruption (was Tracker does not stop indexing)
> https://bugs.launchpad.net/bugs/346912
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Someone wrote "Tracker is not enabled by default". Please allow me to doubt that.

I didn't even know what "tracker" is, until these dialog boxes kept appearing on and on again on my main machine, with no way to get rid of them. Tracker was enabled on two of my notebooks, which were upgraded from Intrepid Ibex (and previously were installed by myself from Ubuntu X86 CDs). I certainly know that I didn't enable tracker manually, so it must have been enabled by default.

On my main machine it wasn't enough to just disable tracker. It was unusable, until I completely uninstalled that tracker thing. I now uninstalled tracker from my other machines, just to be sure that this behaviour won't repeat there.

This bug *is* a very bad annoyance.

gabriela

To turn off the track, in a way that it won't start up again:

(1) Right click on it's magnifying glass icon by the clock, and click quit.
(2) Click on the "System" menu, and goto "Preferences">"StartUp Applications"
(3) Uncheck "Tracker" and "Tracker Applet"

I did that for a while hoping I'd see an update that would fixed the problem before I turned it back on. Eventually, I was looking for some files that I couldn't find, and decided to turn it back on, but the indexing remained corrupted.

Here's how I fixed it. Now, the indexes broke one more time after I did the fix below, but then I did it again, and it has remained fine for some time now. Here's how I got it to work:

(1) Follow the steps listed above, then restart your computer.
(2) Click the "Places" menu and go to "Home Folder".
(3) Go to the "View" menu and check "Show Hidden Files"
(4) Delete all files located in the "/home/lonnie/.cache/tracker" folder, but not the folder itself.
(5) Delete all files located in the "/home/lonnie/.local/share/tracker" folder, but not the folder itself.
(6) Click on the "System" menu, and goto "Preferences">"StartUp Applications"
(7) Make sure "Tracker" and "Tracker Applet" are checked
(8) Restart your machine.

After you login again, the tracker will begin re-indexing all the files. It may not be necessary, but the second time I did these steps, I left my laptop alone, until indexing was complete. You can determine the status of indexing by hovering over the magnifying glass icon by the clock. I even turn off pidgin (which I have added to my startup applications) to further lesson the likely hood that anything might be changing files while the tracker is indexing. This may not have been necessary.

Obviously, this just a work around. This bug needs to be repaired; we can expect average users to have to put up with these steps.

Respectfully,

Lonnie Lee Best
www.lonniebest.com/News/

@gabriela Tracker *was* installed and enabled by default in Intrepid. By upgrading from Intrepid on your two laptops you inherited its configuration.

To test if tracker is enabled (or even installed) by default in Jaunty you need to do a fresh install (in a virtual machine for example). Or just believe the people who say so ;)

Dan - that's wrong. Tracker was installed by default but disabled on Intrepid. It was only ever enabled by default for a very short period after being installed by default for the first time in the Hardy development cycle.

Likewise, it is definately disabled by default on Jaunty (I should know - I wrote the patch to do that for the Jaunty version). Those of you who have never manually enabled tracker but are experiencing this issue are hitting it because of another bug that occurs when you insert removable media (bug 359207). But I can assure you that tracker is definately disabled by default.

I should like to add my humble opinion. My system (quad core 2.4GHz Intel Core2) which worked just fine until upgrading to Ubuntu 9.04 - the Jaunty Jackalope, is now as slow as Windows Vista (sorry for the insult). Launching the about Ubuntu dialog takes nearly a minute. At no time was tracker-indexer enabled, and the dialog box in search and indexing is and always has been unchecked. Right now the tracker-indexer process (which sits in status uniterruptable for 10s of seconds at a time) is hitting 2.5 Gbytes (out of 3.7 available) on a 64-bit machine. I suppose 32-bit users would have the benefit it would crash and cease to be a problem around this point.

No insult to the author but I think you should be disabling this package and removing it from all systems by default, until the problem is found, otherwise users will be deserting ubuntu in droves, as I was thinking of doing until I found this blog

jrrk: I don't think you're suffering from the same bug. Yours is actually much more of a problem! Please open a new report, there must be a very precise problem to tackle - which may be easier to solve than the present bug, in the end. Attaching logs from ~/.local/share/tracker/ will help.

I'd like to add that, for me:

  tracker-processes -r
  [unsure if required - removed 2 remaining files in ~/.cache/tracker]
  /usr/lib/tracker/trackerd &
  tracker-applet &

Seems to have tracker back and working again. I could have logged out and back in I guess after the first 2 lines, but the whole purpose of linux is stability and not having to do all that windows-like stuff :)

Tracker seems happy once again.

Hi Mike.

Thanks so much...next week my Computer "Guru" programmer Son will visit
us...so he will repair this bug I hope!.

Thanks again i will inform you...the finally results!.

Cheers,

Alex!

On Fri, May 22, 2009 at 10:00 AM, Mr. Mike <email address hidden> wrote:

> I'd like to add that, for me:
>
> tracker-processes -r
> [unsure if required - removed 2 remaining files in ~/.cache/tracker]
> /usr/lib/tracker/trackerd &
> tracker-applet &
>
> Seems to have tracker back and working again. I could have logged out
> and back in I guess after the first 2 lines, but the whole purpose of
> linux is stability and not having to do all that windows-like stuff :)
>
> Tracker seems happy once again.
>
> --
> Tracker index corruption (was Tracker does not stop indexing)
> https://bugs.launchpad.net/bugs/346912
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Meta-tracker: New
> Status in “tracker” source package in Ubuntu: Triaged
> Status in tracker in Ubuntu Jaunty: Triaged
>
> Bug description:
> I recently realized that tracker does not always give me the search results
> I expected, meaning that it does not find documents containing certain
> words. A quick look through the indexer preferences, I doubled the "maximal
> amount of text to index" and "maximum number of unique words to index".
> After doing so, the tracker does not stop indexing. The information message
> when I hover over the tracker icons says:
>
> Tracker: Indexing
> Done: 883 of 22296
> Estimated: 33 minutes ...
> Elapsed: 01 minute ...
>
> This message hasn't changed for about a day, and the indexing continues.
> One of my log files is continuously flooded with the following messages:
>
> nasko@serre:~/.local/share/tracker$ tail -n20 tracker-indexer.log
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'previous':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'troubl':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
> 'preprocessor': with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
> 'ac_abs_top_builddir': with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'detail':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'call':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'paramet':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'offshoot':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'with_gcc':
> with fatal error
>
> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'honor':
> with fatal error
>
>
> I would like to have tracker index my files more fully, and yet have it do
> that in a normal manner. Is there a way to prevent this problem?
>

Hello to all of you!

Decided to "Disable" the "Tracker Index"...so now all work well...my
"Computer Guru" son say me that it's totally NOT necessary!.

Thanks so much for your polite advices!

Truly,

Alex!

On Fri, May 22, 2009 at 11:20 AM, Alex Cozac <email address hidden> wrote:

> Hi Mike.
>
> Thanks so much...next week my Computer "Guru" programmer Son will visit
> us...so he will repair this bug I hope!.
>
> Thanks again i will inform you...the finally results!.
>
> Cheers,
>
> Alex!
>
>
> On Fri, May 22, 2009 at 10:00 AM, Mr. Mike <email address hidden> wrote:
>
>> I'd like to add that, for me:
>>
>> tracker-processes -r
>> [unsure if required - removed 2 remaining files in ~/.cache/tracker]
>> /usr/lib/tracker/trackerd &
>> tracker-applet &
>>
>> Seems to have tracker back and working again. I could have logged out
>> and back in I guess after the first 2 lines, but the whole purpose of
>> linux is stability and not having to do all that windows-like stuff :)
>>
>> Tracker seems happy once again.
>>
>> --
>> Tracker index corruption (was Tracker does not stop indexing)
>> https://bugs.launchpad.net/bugs/346912
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>> Status in Meta-tracker: New
>> Status in “tracker” source package in Ubuntu: Triaged
>> Status in tracker in Ubuntu Jaunty: Triaged
>>
>> Bug description:
>> I recently realized that tracker does not always give me the search
>> results I expected, meaning that it does not find documents containing
>> certain words. A quick look through the indexer preferences, I doubled the
>> "maximal amount of text to index" and "maximum number of unique words to
>> index". After doing so, the tracker does not stop indexing. The information
>> message when I hover over the tracker icons says:
>>
>> Tracker: Indexing
>> Done: 883 of 22296
>> Estimated: 33 minutes ...
>> Elapsed: 01 minute ...
>>
>> This message hasn't changed for about a day, and the indexing continues.
>> One of my log files is continuously flooded with the following messages:
>>
>> nasko@serre:~/.local/share/tracker$ tail -n20 tracker-indexer.log
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
>> 'previous': with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'troubl':
>> with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
>> 'preprocessor': with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
>> 'ac_abs_top_builddir': with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'detail':
>> with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'call':
>> with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'paramet':
>> with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
>> 'offshoot': with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word
>> 'with_gcc': with fatal error
>>
>> 22 Mar 2009, 15:11:17: Tracker-Warning **: Could not store word 'honor':
>> with fatal error
>>
>>
>> I would like ...

Hello!

I confirm the problem on a fresh ubuntu 9.04 64-bit installation, after having added a ntfs driver in the "monitored folders" list. The driver was automatically mounted by modifying the fstab file with the following line:
    /dev/sdb1 /media/Dati ntfs-3g defaults,locale=it_IT.UTF-8 0 0

By using the UUID format for the same drive:
    UUID=6C72DB5272DB201E /media/Dati ntfs-3g defaults,locale=it_IT.UTF-8 0 0

and resetting Tracker with
    tracker-processes -r # --hard-reset

the problem has been solved.
I don't know if it may be a general issue or only a coincidence... let me know!

This bug affected me today. I killed the tracker processes and deleted the files in those folders
~/.cache/tracker and ~./.local/share/tracker/data and then restarted the program ( no need to reboot) and works fine now. I have not made any changes to my torrent program in weeks and this hit me today. I have not used the update manager in a couple weeks due to no recent updates available for my system. Just letting you know that this bug is still causing problems.

I also had this bug after upgrading to 9.04, and
  sudo apt-get install tracker-utils
  tracker-processes -r # --hard-reset
solved the problem. However, it occured again after I accidentally pulled the plug of my computer. I now uninstalled tracker. As savebart, I also have a ntfs drive, but it's mounted with an UUID.

After updates tracker indexing works without problems on my machine. No further occurrences of index corruption errors.
OS Ubuntu 9.04 64-bit on Ext4 (root) and a few partitions mounted (Ext3, Ext4, NTFS) with indexing activated for some of their folders. (Note: the setting "index mounted media" switched off)

I've been having exactly the same issues as many of the above posters have had. I'm hoping to have a go at the Milan solution a bit later (deleting a few hidden files). One other piece of info though.
A piece of extra info not necessarily mentioned above:
there is no problem until I put a removable memory device in (it's happened both with an SD card and a usb memory-stick), within about a minute of the insertion of such a device the pop up with the choices that won't go away is on screen, and if I choose re-index I can't use my machine because it spends a long time greyed-out.

I had the problem on several occasions in Jaunty, then about 6 months of peace, and now the problem is back in Karmic...
tracker-processes -r and re-indexing the drive is a bit of a pain though

I still have the same Problem with the tracker. I disabled it 2 months ago because it took so much CPU and a lot of my harddisk-resource. I enabled it yesterday an got the told error.

Jaunty is well past its EOL. Closing as Won't Fix.

is this still a problem in focal or later?

have not seen this one jet in newer version.