Red Hat Bugzilla – Bug 426060
multiple trackerd running for days consuming 100% of cpu
Last modified: 2008-02-07 16:01:06 EST
Description of problem:
I happened to run top, and discovered five copies of trackerd running. Why? It
has been running for days!! How can I find out what it is stuck on? Why is it
sensible to turn on trackerd by default for all of my $HOME? I'm a developer,
I have 82G of weird code, unconventional file types, binaries, and other junk in
my home directory.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
No more than 1 copy at a time.
Not sure that indexing is even useful to me, so it should do what it wants
without me noticing it.
(In reply to comment #0)
> Description of problem:
> I happened to run top, and discovered five copies of trackerd running. Why?
I might have make a mistake with the patch I applied on top of tracker-0.6.4;
I've reverted it, please try tracker-0.6.4-3 (available @
> It has been running for days!! How can I find out what it is stuck on? Why is it
> sensible to turn on trackerd by default for all of my $HOME? I'm a developer,
That's actually a sensible thing to do IMHO; you can configure directories to
watch (or not watch) to your liking using System->Preference->Search and Indexing.
Hmm, don't be quite so quick to back out your latest changes.
I'm running tracker-0.6.4-2 now, but the five copies of tracker that were
running earlier could have been from an earlier release since I think 0.6.4-2
only came out today?
I only have one copy of trackerd running now, and I've tried things like
logout+login to see if I could get more copies to show up again, and I can't.
I have your 0.6.4-3, but I don't know how to recreate the multiple copy problem
to see if it fixes it.
Thanks for the pointer to the preferences. The defaults seem to be to use
maximum memory and maximum cpu consumption. Perhaps these should be backed off
Would it worthwile doing a quick "du -s" check of a file tree, and asking the
user, before diving in and indexing it?
(In reply to comment #2)
> Hmm, don't be quite so quick to back out your latest changes.
I think I'll leave it out for now, and study the patch more closely.
> Thanks for the pointer to the preferences. The defaults seem to be to use
> maximum memory and maximum cpu consumption. Perhaps these should be backed off
> a bit.
Tracker design strategy is not to use to much memory, and use as much cpu power
in a short burst of time without getting in the way of other useful apps (for
faster indexing). I think the defaults are alright for most 'normal' use cases.
> Would it worthwile doing a quick "du -s" check of a file tree, and asking the
> user, before diving in and indexing it?
> Tracker design strategy is not to use to much memory, and use as much cpu power
> in a short burst of time without getting in the way of other useful apps
Good objective, but thats not what I've observed so far.
tracker-0.6.4-1.fc8.x86_64 also seems to be affected. There are two processes
running, with one consuming 100 % CPU, every boot.
zack 2505 0.0 0.3 33188 3856 ? SNl 10:41 0:02 trackerd
zack 2519 81.4 0.1 7908 1624 ? T 10:41 41:23 /usr/bin/trackerd
I have 2519 in gdb right now:
Thread 1 (Thread 0xb7f65920 (LWP 2519)):
#0 0x005975f0 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x0807a23b in tracker_error (
message=0x80946c0 "ERROR: trackerd already running on your session dbus -
exiting...") at tracker-utils.c:3500
#2 0x08067819 in tracker_dbus_init () at tracker-dbus.c:75
#3 0x08050150 in main (argc=1, argv=0xbfd71fa4) at trackerd.c:2491
#4 0x003f24a0 in __libc_start_main () from /lib/libc.so.6
#5 0x0804e551 in _start ()
And let's see the strace output:
sigreturn() = ? (mask now )
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
...repeated roughly one billion times per second. It must be killed with -9.
Created attachment 292828 [details]
Hmm, I think I may have fixed it. From trackerd/tracker-utils.c:3500
This is being called by tracker_dbus_init(), which is called before any of the
GMutexes are initialized with g_mutex_new(). So it's essentially
g_mutex_lock(NULL). In this patch I moved all the g_mutex_new() calls to
*before* tracker_dbus_init() is called. I built it and it seems to work for me,
but then again I don't guarantee I know what I'm talking about ;)
Thanks for the patch. Can you please test the build at
http://koji.fedoraproject.org/koji/taskinfo?taskID=370916, and confirm if it fix
the issue for you or not. The build contained fixes backported from upstream svn.
I'm sorry the build I directed you to earlier was targeted at rawhide, a build
targeted at f8-updates is at
Hmm, I am getting python tracebacks while trying to fetch f8 build.
(In reply to comment #10)
> Hmm, I am getting python tracebacks while trying to fetch f8 build.
Please try again.
No luck. Actually, an attempt to fetch any file from that scratch build fails.
I think that build has expired, I've performed a fresh (scratch) build here,
OK, I was able to grab the files. Feedback soon to follow.
So far, the fix seems to be working. Thanks.
tracker-0.6.4-4.fc8,o3read-0.0.4-1.fc8 has been submitted as an update for Fedora 8
tracker-0.6.4-4.fc7.1,o3read-0.0.4-1.fc7 has been submitted as an update for Fedora 7
tracker-0.6.4-4.fc7.1, o3read-0.0.4-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update tracker o3read'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F7/FEDORA-2008-1145
Looks like tracker-0.6.4-5.fc9 fixed this for rawhide.
tracker-0.6.4-4.fc8, o3read-0.0.4-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
tracker-0.6.4-4.fc7.1, o3read-0.0.4-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.