Bug 426060 - multiple trackerd running for days consuming 100% of cpu
Summary: multiple trackerd running for days consuming 100% of cpu
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tracker
Version: rawhide
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Deji Akingunola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-18 02:54 UTC by John Ellson
Modified: 2008-02-07 21:01 UTC (History)
2 users (show)

Fixed In Version: 0.6.4-4.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-07 20:59:30 UTC
Type: ---


Attachments (Terms of Use)
proposed patch (2.32 KB, patch)
2008-01-24 17:35 UTC, Zack Cerza
no flags Details | Diff

Description John Ellson 2007-12-18 02:54:25 UTC
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):
tracker-0.6.4-2.fc9.x86_64

How reproducible:
??

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
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.

Additional info:

Comment 1 Deji Akingunola 2007-12-18 04:41:20 UTC
(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 @
http://koji.fedoraproject.org/koji/buildinfo?buildID=28417) 
> 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.




Comment 2 John Ellson 2007-12-18 05:15:16 UTC
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
a bit.

Would it worthwile doing a quick "du -s" check of a file tree, and asking the
user, before diving in and indexing it? 

Comment 3 Deji Akingunola 2007-12-18 05:59:04 UTC
(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? 



Comment 4 John Ellson 2007-12-18 06:08:59 UTC
> 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.
  

Comment 5 Julian Sikorski 2008-01-03 08:36:15 UTC
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.

Comment 6 Zack Cerza 2008-01-24 16:34:14 UTC
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.

tracker-0.6.4-4.fc9

Comment 7 Zack Cerza 2008-01-24 17:35:52 UTC
Created attachment 292828 [details]
proposed patch

Hmm, I think I may have fixed it. From trackerd/tracker-utils.c:3500

    g_mutex_lock (tracker->log_access_mutex);

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 ;)

Comment 8 Deji Akingunola 2008-01-24 19:58:52 UTC
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.

Comment 9 Deji Akingunola 2008-01-25 02:48:29 UTC
I'm sorry the build I directed you to earlier was targeted at rawhide, a build
targeted at f8-updates is at
http://koji.fedoraproject.org/koji/taskinfo?taskID=371133

Comment 10 Julian Sikorski 2008-01-26 10:37:02 UTC
Hmm, I am getting python tracebacks while trying to fetch f8 build.

Comment 11 Deji Akingunola 2008-01-26 12:09:38 UTC
(In reply to comment #10)
> Hmm, I am getting python tracebacks while trying to fetch f8 build.

Please try again.


Comment 12 Julian Sikorski 2008-01-26 12:48:25 UTC
No luck. Actually, an attempt to fetch any file from that scratch build fails.

Comment 13 Deji Akingunola 2008-01-26 15:04:18 UTC
I think that build has expired, I've performed a fresh (scratch) build here,
http://koji.fedoraproject.org/koji/taskinfo?taskID=374517

Comment 14 Julian Sikorski 2008-01-26 20:40:14 UTC
OK, I was able to grab the files. Feedback soon to follow.

Comment 15 Julian Sikorski 2008-01-27 09:47:22 UTC
So far, the fix seems to be working. Thanks.

Comment 16 Fedora Update System 2008-01-27 23:09:07 UTC
tracker-0.6.4-4.fc8,o3read-0.0.4-1.fc8 has been submitted as an update for Fedora 8

Comment 17 Fedora Update System 2008-01-27 23:10:21 UTC
tracker-0.6.4-4.fc7.1,o3read-0.0.4-1.fc7 has been submitted as an update for Fedora 7

Comment 18 Fedora Update System 2008-01-29 05:15:21 UTC
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

Comment 19 Zack Cerza 2008-01-30 16:11:35 UTC
Looks like tracker-0.6.4-5.fc9 fixed this for rawhide.

Comment 20 Fedora Update System 2008-02-07 20:59:28 UTC
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.

Comment 21 Fedora Update System 2008-02-07 21:01:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.