Bug 1159991

Summary:	gvfsd-metadata using 100% CPU for extended time (hours after hours)
Product:	[Fedora] Fedora	Reporter:	Feng Yu <rainwoodman>
Component:	gvfs	Assignee:	Ondrej Holy <oholy>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	alexl, bnocera, oholy, rainwoodman
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	gvfs-1.16.4-3.fc19	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-07 04:36:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Feng Yu 2014-11-03 19:42:40 UTC

Description of problem:

gvfsd-metadata using 100% CPU for extended time (hours after hours)
After booting and idling for a while (~ 20 mins), gvfsd-metadata tops the cpu usage and runs forever. It doesn't seem to ever finish.

Version-Release number of selected component (if applicable):
gvfs-1.16.4-2.fc19.x86_64

How reproducible:

Always; but difficult.

Steps to Reproduce:
1. Boot up. 
2. running one day or two; suspende and wake up multiple times (no gvfsd-metadata issue)
3. wake up the computer and go away for 20min
4. come back see gvfsd-metadata using 100% cpu and keeps the harddrive spinning.
5. gdb attaching to gvfsd-metadata reveals it seems to be in a deadloop transversal a glist.

Actual results:
computer gets very hot and slow, harddrive is overused.

Expected results:
gvfsd-metadata finishes and quit or timeout and kills itself.

Additional info:

Comment 1 Ondrej Holy 2014-11-04 10:30:54 UTC

Thanks for your bugreport. This really should not happen...

Is your ~/.local/share/gvfs-metadata/ on a local filesystem?

Could you provide more exact info where it is looping? Are new files continually recreated in ~/.local/share/gvfs-metadata/ (maybe strace could be usefull)?

There is one more upstream fix which is not applied to your gvfs version. Could you try following steps:
https://bugzilla.gnome.org/show_bug.cgi?id=637095#c47

to reproduce the issue and compare the symptoms?

Comment 2 Feng Yu 2014-11-10 04:17:29 UTC

Yes. Saving the image as http://rossl.org/junk/meta.html to download reproduces the bug: gvfsd-metadata hops up.

On my F19 system with a ssds, it uses 100% cpus

It also affected my other F20 box too; it doesn't have an SSD, so just a gvfsd-metadata process there with D status on `top' -- and it never finishes.

~/.local/share/gvfs-metadata is local on either machines.

Could you backport the fix?

This is really serious as it will sooner or later ruin the disks!

Comment 3 Ondrej Holy 2014-11-11 09:30:26 UTC

You are right, this is serious and we should have did it already. So it is backported now for F19. Fix for F20 will be coming soon.

Comment 4 Fedora Update System 2014-11-18 10:40:18 UTC

gvfs-1.16.4-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gvfs-1.16.4-3.fc19

Comment 5 Fedora Update System 2014-11-19 15:57:25 UTC

Package gvfs-1.16.4-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gvfs-1.16.4-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15377/gvfs-1.16.4-3.fc19
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2014-12-07 04:36:26 UTC

gvfs-1.16.4-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.