Bug 426060 - multiple trackerd running for days consuming 100% of cpu
multiple trackerd running for days consuming 100% of cpu
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: tracker (Show other bugs)
rawhide
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Deji Akingunola
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-17 21:54 EST by John Ellson
Modified: 2008-02-07 16:01 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.6.4-4.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 15:59:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description John Ellson 2007-12-17 21:54:25 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):
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-17 23:41:20 EST
(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 00:15:16 EST
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 00:59:04 EST
(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 01:08:59 EST
> 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 03:36:15 EST
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 11:34:14 EST
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 12:35:52 EST
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 14:58:52 EST
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-24 21:48:29 EST
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 05:37:02 EST
Hmm, I am getting python tracebacks while trying to fetch f8 build.
Comment 11 Deji Akingunola 2008-01-26 07:09:38 EST
(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 07:48:25 EST
No luck. Actually, an attempt to fetch any file from that scratch build fails.
Comment 13 Deji Akingunola 2008-01-26 10:04:18 EST
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 15:40:14 EST
OK, I was able to grab the files. Feedback soon to follow.
Comment 15 Julian Sikorski 2008-01-27 04:47:22 EST
So far, the fix seems to be working. Thanks.
Comment 16 Fedora Update System 2008-01-27 18:09:07 EST
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 18:10:21 EST
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 00:15:21 EST
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 11:11:35 EST
Looks like tracker-0.6.4-5.fc9 fixed this for rawhide.
Comment 20 Fedora Update System 2008-02-07 15:59:28 EST
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 16:01:06 EST
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.