Bug 426060
Summary: | multiple trackerd running for days consuming 100% of cpu | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Ellson <john.ellson> | ||||
Component: | tracker | Assignee: | Deji Akingunola <dakingun> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | CC: | belegdol, zcerza | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 0.6.4-4.fc8 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-02-07 20:59:30 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
John Ellson
2007-12-18 02:54:25 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. 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? (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. tracker-0.6.4-4.fc9 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 ;)
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 http://koji.fedoraproject.org/koji/taskinfo?taskID=371133 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, http://koji.fedoraproject.org/koji/taskinfo?taskID=374517 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. |