[karmic] Trackerd goes into infinite loop indexing .xsession-errors

Bug #458995 reported by Jerry Chong
64
This bug affects 11 people
Affects Status Importance Assigned to Milestone
tracker (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: tracker

A few seconds after start indexing, Tracker starts consuming 100% cpu (or 50% for dual core), and checking .local/share/tracker/trackerd.log shows that trackerd is stuck in an infinite loop:

23 Oct 2009, 19:27:22: Tracker: Received monitor event:2->'IN_MODIFY' for file:'/home/zanglang/.xsession-errors' (cookie:0)
23 Oct 2009, 19:27:22: Tracker: Received monitor event:2->'IN_MODIFY' for file:'/home/zanglang/.xsession-errors' (cookie:0)
23 Oct 2009, 19:27:22: Tracker: Received monitor event:2->'IN_MODIFY' for file:'/home/zanglang/.xsession-errors' (cookie:0)
23 Oct 2009, 19:27:22: Tracker: Received monitor event:2->'IN_MODIFY' for file:'/home/zanglang/.xsession-errors' (cookie:0)
...

Checking tracker-preferences shows that I indeed had ".xsession-errors" listed under Ignored File Patterns.

The bug appears to be 100% reproducible everytime I start trackerd.

I'm not sure if it's related to previous 100% CPU bugs, but Googling returns nothing about this .xession-error problem, so I assume it's not a duplicate.

ProblemType: Bug
Architecture: i386
Date: Fri Oct 23 19:27:36 2009
DistroRelease: Ubuntu 9.10
Package: tracker 0.6.95-1ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.47-generic
SourcePackage: tracker
Uname: Linux 2.6.31-14-generic i686

Revision history for this message
Jerry Chong (zanglang) wrote :
description: updated
Revision history for this message
Anita (a-lewis) wrote :

This fills up my home directory to 100% real fast; so I consider it important!

Revision history for this message
Anita (a-lewis) wrote :

More info. First this is happening since I upgraded from jaunty to karmic. Now I find that tracker is not doing this if I start it manually from a terminal with '/usr/lib/tracker/trackerd &'. I have the problem with I start it from autostart selecting it and the tracker-applet in Startup Applications in Systems/Preferences.

Revision history for this message
Anita (a-lewis) wrote :

I moved the following directories to temporary spot to see what happened when tracker made them new: ~/.config/tracker; ~/.cache/tracker; ~/.local/share/tracker. I then checked trackerd and tracker-applet to start under /System/Preferences/Startup Applications. It seems to be running fine and not producing the huge .xsession-errors file. I've saved the old directories if anyone wants to try to look at comparisons between what is in the old and what is in the new.

Revision history for this message
Nicolas Grilly (nicolas-grilly) wrote :

Same problem on my computer just after upgrading from Jaunty to Karmic.

.xession-errors is filled up with the same message:
Tracker-Message: Received monitor event:2->'IN_MODIFY' for file:'/home/ngrilly/.xsession-errors' (cookie:0)

This is very annoying because the CPU is busy and the disk is full.

Revision history for this message
Derek Chen-Becker (dchenbecker) wrote :

I can confirm the same behavior on an upgrade from jaunty to karmic. Manually adding ".xsession-errors" to the ignore patterns in the search preferences stops the behavior.

Revision history for this message
Derek Chen-Becker (dchenbecker) wrote :

Well, this is bad news. Even with the manual ignore on .xsession-errors, tracker decided some time last night to start tracking it anyways. I woke up this morning to a home drive that had gone from 156GB free to 10MB (!) free. I've completely disabled tracker at this point.

Revision history for this message
Forest (foresto) wrote :
Revision history for this message
Jerry Chong (zanglang) wrote :

Hard to tell for #239391, since it looks that there are multiple bugs symptoms in there, and the reports span from version 0.6.6 to 0.6.95. The Fedora post is spot on though.

Changed in tracker (Ubuntu):
status: New → Confirmed
Revision history for this message
Patrik Jansson (patrikja) wrote :

Same problem here after upgrading from 9.04 to 9.10. Deleting .xsession-errors stops the problem for a while but after reboot it is back and growing at the speed the system can bear.

Revision history for this message
Patrik Jansson (patrikja) wrote :

I tried verbosity level 1 (was 3 because of a tracker bug a year or so ago) and making this
NoIndexFileTypes=.xsession-errors;
in $HOME/.config/tracker/tracker.cfg

But, still, after reboot I have the same violently growing .xsession-errors (it is already at around 1Gb after writing this entry:-()

patrikj@hip:~$ uname -a
Linux hip 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:00:22 UTC 2009 i686 GNU/Linux
patrikj@hip:~$ more /etc/issue
Ubuntu 9.10 \n \l

Revision history for this message
Anita (a-lewis) wrote :

Fix that worked for me:

Delete the following and restart tracker:

 ~/.config/tracker
~/.cache/tracker
~/.local/share/tracker

Tracker will remake them. It must be a problem with a config file from the older version.

Revision history for this message
Forest (foresto) wrote :

Thanks, Anita. I followed your advice and, trackerd has been behaving for the past day or so. I still have .xsession-errors in my exclude list, though I don't know if it's necessary.

Revision history for this message
Bruce MacDonald (b-macdonald-auckland) wrote :

I can confirm this bug too, after getting around bug 511015. After getting tracker to complete indexing, it seemed fine. However, after reboot I have the infinite loop, high CPU, and growing .xsession-errors symptoms. Also, the tooltip for tracker-applet says that tracker is optimizing the database, while the high CPU usage is happening. After turning off autostart for tracker, logging out and in again, and running it by hand, it is ok. Will see how it goes for awhile. It seems to be searching ok (I haven't restarted tracker from scratch).

Revision history for this message
Bruce MacDonald (b-macdonald-auckland) wrote :

Not ok. trackerd keeps running up to use all CPU after it finishes a refresh to the database (crawl and index).

Revision history for this message
Sonal Santan (sonal-santan) wrote :

I had similar trouble but tweaked its config file to workaround this.

[1] open ~/.config/tracker/tracker.cfg in your favorite editor.
[2] Change Verbosity to 0. Something like the following--

# Log Verbosity (0=errors, 1=minimal, 2=detailed, 3=debug)
Verbosity=0

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

I have a similar problem. When it happens, the tracker applet shows a "!" and say "paused". If I click on the applet, then choose (pause), nothing happens. Then I deselect the pause and the usage goes to almost zero, at least during a while (hours). Then it goes to 100% again.

I changed the verbosity to 2. I hope to see something in the log when it happens again.

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

Ok, happened again. Trackerd is now at 100% CPU:

1889 romano 36 16 61164 15m 4188 R 100 0.4 45:12.05 trackerd

Two hours ago, after a change in a file made by my local dovecot server, decided to go into pause mode but using 100% CPU. The last messages on the log where:

22 Sep 2010, 14:48:27: Tracker: Received monitor event:8->'IN_CLOSE_WRITE | IN_C
LOSE*' for file:'/home/romano/lib/Mail/VRISCU' (cookie:0)
22 Sep 2010, 14:48:29: Tracker: We are paused, sending nothing to the index unti
l we are unpaused
22 Sep 2010, 14:48:31: Tracker: We are paused, sending nothing to the index unti
l we are unpaused

Notice, I was not even seated at the PC. It went to pause mode alone. The log message is repeated every 2 seconds (why?). If I right click on the applet, the "pause all indexing" is unticked. I ticked it:

22 Sep 2010, 15:30:53: Tracker: We are paused, sending nothing to the index unti
l we are unpaused
22 Sep 2010, 15:30:54: Tracker: <--- [123] DBus request to set daemon boolean op
tion, key:'Pause', value:true
22 Sep 2010, 15:30:54: Tracker: New DBus request, not pausing indexer, already i
n paused state
22 Sep 2010, 15:30:54: Tracker: ---> [123] Success, no error given

Still 100% CPU, still the same message every 2 seconds. Now I untick the "pause all indexing" again:

22 Sep 2010, 15:32:04: Tracker: <--- [124] DBus request to set daemon boolean option, key:'Pause', value:false
22 Sep 2010, 15:32:04: Tracker: New DBus request, not pausing indexer, already in paused state
22 Sep 2010, 15:32:04: Tracker: ---> [124] Success, no error given
22 Sep 2010, 15:32:04: Tracker: Finished crawling files in 1996.0914 seconds
22 Sep 2010, 15:32:04: Tracker: Found 1521 directories, ignored 119 directories
22 Sep 2010, 15:32:04: Tracker: Found 29729 files, ignored 613 files
22 Sep 2010, 15:32:04: Tracker: Received monitor event:4->'IN_ATTRIB' for file:'/home/romano/management/viajes/nantes10/SSSUP S.Anna.doc' (cookie:0)

...and then a lot of more data, apparently receiving all signals/events that were missed when in the "nasty paused" state. Now CPU utilization is normal.

I can attach/send the full log if someone is interested.

From past experiences, now trackerd will behave during hours/days. Then it will fall again in the "bogus paused" state and start using 100% CPU.

At the same time, .xsession-erros has growth to unbearable size (2G +) with the message:

Tracker-Message: Received monitor event:2->'IN_MODIFY' for file:'/home/romano/.xsession-errors' (cookie:0)

repeated over and over.

This is with an up-to-date ubuntu 10.04

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

...and I had to kill trackerd at the end. Nice.

Will try to apply the workaround above. It's a pity, tracker is such a nice tool when it works and not DOS you system...

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

...and then I killed trackerd via "killall trackerd", and I cannot find a way to have it back. Logging out-in say me that there is trackerd and tracker-indexer running, but I have no applet, and running manually tracker-applet (there is no such a thing in the applet list) does nothing.

Sigh. There was a time, when I had a .xinitrc file I can edit, check and even rerun...

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

Other bug subscribers

Remote bug watches

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