gvfsd-metadata causes 100% CPU usage

Bug #517021 reported by mucku on 2010-02-04
348
This bug affects 93 people
Affects Status Importance Assigned to Milestone
gvfs
Fix Released
Medium
gvfs (Debian)
Fix Released
Unknown
gvfs (Ubuntu)
Medium
Ubuntu Desktop Bugs
Precise
Undecided
Unassigned
Trusty
Undecided
Unassigned
Utopic
Undecided
Unassigned
Vivid
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gvfs

Failure to write metadata results in an infinite loop that keeps trying to write, thousands of times per second.

Steps to reproduce:
1. Open Firefox
2. Save a data: URL (URL that contains the content, with several thousands bytes, often generated by webapps or extensions) as file

(There are other ways to run into this problem, e.g. disk full or other error situations. data: URLs are just the easiest way to reproduce.)

Actual result:
- File is saved
- 100% CPU
- Extremely high number of file operations by gvfs - billions
- Never stops

Expected result:
Failure to write metadata should just fail, not try again

Fix:
Patch available and accepted by GNOME
https://bugzilla.gnome.org/show_bug.cgi?id=637095

--- Original description ---
After installing 9.10 Ubuntu 64bit browsing and opening folder in nautilus or Gnome-commander take several minutes when there are many files in it e.g. 10.000. Interestingly Midnight-commander does not have this problem. Opening such folders does not hang with MC.
Using "top" i can see that "gvfsd-metadata" is using 100% CPU and when i kill it the computer stops "hanging". I am using the 32bit version of Karmic too and there is no such Problem (although tested on a different computer).

Please fix this because it is highly annyoing. Right now i am killing it every 20s with the watch command to be able to work at all.

Pedro Villavicencio (pedro) wrote :

Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

Changed in gvfs (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Medium
status: New → Incomplete
mucku (dereinsameberg) wrote :

Sorry I don't know how to retrieve the backtrace. The program comes up and disappears. When I use the steps in the How-to I can't really go further when i write "(gdb) continue". It just says "continuing". I have no real idea about programming.

I uploaded the *.txt. Could you tell me if that is the right file and what you are looking for? The program starts running and disappearing. So I can't really pinpoint it like in that How-to.

Greetings

mucku (dereinsameberg) wrote :

Pressing F5 in a folder to refresh its contents seems to invoke "gvfsd-metadata". Whatever it does.

Donny Kurnia (donnykurnia) wrote :

In my system, this bug is happened when I copy or move files from one folder to another.

Gorka Navarrete (emrys) wrote :

The problem persists after an upgrade to lucid (64-bits).

It occurs after copying a few thousand files.

It makes the system highly unusable and hot.

pothos (pothos) wrote :

I have also the problem after booting and then sometimes.
I have also errors in dmesg:

[ 149.466717] __ratelimit: 24 callbacks suppressed
[ 149.466723] gvfsd-metadata[2336]: segfault at 7fff955a3ff8 ip 00007f2ebe806665 sp 00007fff955a4000 error 6 in libc-2.11.1.so[7f2ebe78f000+178000]
[ 181.933416] gvfsd-metadata[2369]: segfault at 7fff81effff8 ip 00007ffee2ea1fa3 sp 00007fff81efffd0 error 6 in libc-2.11.1.so[7ffee2e27000+178000]
[ 214.045839] gvfsd-metadata[2388]: segfault at 7fffab1cbff8 ip 00007f7cd6c31669 sp 00007fffab1cc000 error 6 in libc-2.11.1.so[7f7cd6bba000+178000]
[ 246.264777] gvfsd-metadata[2390]: segfault at 7fff1f35eff8 ip 00007f09d1795bb9 sp 00007fff1f35f000 error 6 in libc-2.11.1.so[7f09d1719000+178000]
[ 278.625348] gvfsd-metadata[2392]: segfault at 7ffffcdf4ff8 ip 00007fd5d44d2669 sp 00007ffffcdf5000 error 6 in libc-2.11.1.so[7fd5d445b000+178000]
[ 310.613414] gvfsd-metadata[2394]: segfault at 7fff90f9cff8 ip 00007f402c871bb9 sp 00007fff90f9d000 error 6 in libc-2.11.1.so[7f402c7f5000+178000]
[ 342.741799] gvfsd-metadata[2540]: segfault at 7fff69bdafe0 ip 00007fa9ede48af0 sp 00007fff69bdb008 error 6 in libc-2.11.1.so[7fa9eddcc000+178000]
[ 374.813577] gvfsd-metadata[2570]: segfault at 7ffff0265ff8 ip 00007f6417a2866d sp 00007ffff0266000 error 6 in libc-2.11.1.so[7f64179ab000+178000]
[ 407.074920] gvfsd-metadata[2673]: segfault at 7fff57255fd8 ip 00007f552d9dffa8 sp 00007fff57255fe0 error 6 in libc-2.11.1.so[7f552d965000+178000]
[ 817.351735] gvfsd-metadata[3277]: segfault at 7fffc92e4ff8 ip 00007f7c17d210c3 sp 00007fffc92e5000 error 6 in libglib-2.0.so.0.2400.0[7f7c17cc5000+db000]
[ 854.474189] gvfsd-metadata[3301]: segfault at 7fff08cfcfe8 ip 00007f80dea4bfa8 sp 00007fff08cfcff0 error 6 in libc-2.11.1.so[7f80de9d1000+178000]
[ 895.449230] gvfsd-metadata[3321]: segfault at 7fff4efd2ff8 ip 00007f837659966d sp 00007fff4efd3000 error 6 in libc-2.11.1.so[7f837651c000+178000]
[ 899.975967] modplug0:sink[3439]: segfault at ffffffffeabfd588 ip 00007f62f0757726 sp 00007f62e43fa9e0 error 4 in libc-2.11.1.so[7f62f06dc000+178000]
[ 912.824717] modplug0:sink[3472]: segfault at ffffffffeaf16fc8 ip 00007fdcee020726 sp 00007fdcde2fc9e0 error 4 in libc-2.11.1.so[7fdcedfa5000+178000]

mucku (dereinsameberg) wrote :

Hmm I had hoped it would be fixed in 10.04. So upgrading might not be the cure if this still persists in Lucid.
So is the problem connected to "libc" ?

pothos (pothos) wrote :

My disk space was really full at one moment, no byte left free. People say, that does corrupt the files in the ~/.local/share/gvfs-metadata folder, so the gvfsd-metadata can't read it without being screwed up. So the content of this folder should be deleted: rm -rf ~/.local/share/gvfs-metadata

mucku (dereinsameberg) wrote :

Wow, that tip with

rm -rf ~/.local/share/gvfs-metadata

actually helped.

After reboot "gvfs-metadata" is not really coming up anymore in top.
Thank you a lot. That was extremely annoying. And as I remember... I was really filling up my disk with a lot of data.

mucku (dereinsameberg) wrote :

How about the rest of you guys?
If it fixes your problem too, then we should close this bug report. If your problem persists maybe open a new one for your specific case. What is the protocol for handling this?

Donny Kurnia (donnykurnia) wrote :

Yes, mucku

Your solution worked in my laptop. It seems that ~/.local/share/gvfs-metadata/ folder contain metadata from network that I have connected with. The problems is, I only connected to those network once.

Nautilus/gvfsd seems to crawl any network (specially samba network) when I'm connected to the network in my office and in some hotspot area. When I back home, gvfsd try to update the metadata by reopen the samba network folder that of course not exist in my home network.

So, I suspect that this is the cause of gvfsd-metadata to taking whole CPU resource to try to find the 'missing' directory and read it's content to update the metadata. Deleting metadata files will make the gvfsd 'forget' those directories.

Rune Philosof (olberd) on 2010-08-17
description: updated
Changed in gvfs (Ubuntu):
status: Incomplete → New
mucku (dereinsameberg) on 2011-01-06
Changed in gvfs (Ubuntu):
status: New → Fix Released
Vladimir (vladimir-kozlov) wrote :

Why you changed the status to "Fix released"?

What you mean by "fix" - in my opinon periodical manual (or made by cron) removing of the contents of ~/.local/share/gvfs-metadata/ and killing of gvfsd-metadata processes could not be treated as "fix".

The problem still persists on 10.04 ans is very annoying, especially when home directories reside on nfs server: it lead to server's hang very often: each workstation begins to generate up to 100mbit/sec traffic.

mucku (dereinsameberg) wrote :

I thought it was a weird behavior specific to very few people. I didn't know it is a general bug and it was hanging for half a year without anybody caring so i changed it to fixed. Will reopen if you want.

Changed in gvfs (Ubuntu):
status: Fix Released → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Ben Hall (bhall-f) wrote :

This is a problem that affects us on a daily basis. When our user home directory quotas are full and they attempt file operations in nautilus it causes the gvfsd-metadata process to use over 80% of a CPU and generates excessive nfs traffic. This is a problem that needs to be fixed.

Wayne Scott (wsc9tt) wrote :

Just adding my vote here. I have seen this ever since upgrading to 11.10 on multiple machines.
It is really annoying.

This happens on a 64-bit desktop and a 32-bit laptop. (I can't remember, but I think the laptop had 11.10 installed
directly and wasn't an upgrade.)

I have been using Ubuntu for years and haven't see this on earlier releases.

Bless you Mucku!
My disk is not full but I started to get kernel error messages whenever I browsed with nautilus (Not with Thunar) one particular disk partition (1.8TB) and moving a tiny file from a directory to another would take ages.
Removing ~/.local/share/gvfs-metadata solved the problem! :-D
This bug deserves a fix by the gvfs developers.

Thank you again!

> The problem still persists on 10.04 ans is very annoying, especially when
> home directories reside on nfs server: it lead to server's hang very often:
> each workstation begins to generate up to 100mbit/sec traffic.

This is a serious issue of it's own, please see bug #720927.

Also see:

Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624507
Fedora/RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=561904
GNOME (upstream): https://bugzilla.gnome.org/show_bug.cgi?id=637095

Cheers,

Adrian

Nicola Larosa (teknico) wrote :

This happened to me today. Same problem, same workaround.

Paul Sokolovsky (pfalcon) wrote :

Brave guy at http://www.linuxquestions.org/questions/linux-newbie-8/what-is-gvfsd-metadata-4175458624/ proposes more permanent workaround: "chmod -x /usr/lib/gvfs/gvfsd-metadata". If you think about it for a bit, that solution has its merit: if you already have your metadata in your file system, then why would you want to run stupid buggy-for-years gnome daemons for its kinds of "metadata"?

Moses Moore (moses-mozai) wrote :

I've seen this behaviour even when the harddrive isn't full. It eats CPU and hits the harddrive with thousands of ioops per second (seen using iotop). I've left it running for eight hours once, hoping it would sort itself out. Deleting ~/.local/share/gvfs-metadata and restarting the daemon "solves" the problem, but destruction is a terrible way to fix a problem, and it doens't prevent the problem from happening again days or weeks later.

Galen Thurber (godfree2) wrote :

I'll make a guess it could be happening after a bleachbit wipe free space (home folder) operation.
That just happened to me.

It happened to me on a fresh install of 12.04.
It's not about full disk partitions because I'm not even at 50% of my disks.
It might be about indexing large files (I downloaded several VMs).
Removing the exec permissions on /usr/lib/gvfs/gvfsd-metadata "fixes" it but I'm losing some functionality. Most evidently, the desktop doesn't remember the position of the icons across logout/logins. I wonder what else is broken.

isync (o-zucker) wrote :

Fresh install Ubuntu 14.04, and actually I do had one disk (although not system disk) completely full a few days ago.

Today, without any apparent reason, disk I/O indicator LED not going off anymore (I don't know for how long) and system disk is an SSD. With a spinning disk this would've been serious thrashing. top told me ~20% CPU from gvfsd-metadata and iotop was reporting >1500K/s from that process.

I simply immediately shut down. After reboot: silence. Yet, after reading some posts, I rm wiped the ~/.local/share/gvfs-metadata folder. For now, that solved it.

Ben Bucksch (benbucksch) wrote :

Because some people here apparently treat silence as "I guess this is fixed", I'll spam here and say this keeps happening for me regularly as well. I've tried various things, killing the process, killing the directory IIRC, but it keeps coming back with 100%, maybe once a week or so, but it's irregular.

1.
I've probably seen 100 posts on the Internet saying to delete the metadata folder, but that's not a solution:
Even if it does get corrupted, the program MUST NOT go crazy and into an infinite loop or hog the CPU.
That said, I do NOT think that metadata file corruption is the problem, because the problem keeps coming back for me.

2.
I have huge NFS drives with many files mounted. If it tries to index or capture them, then it's sure to cause problems. People above said that it tries to index Samba drives. That's massively misguided and should not happen. It should only index local drives. Network drives can be huge, and often contain data that's not important to this user, but to other employees. In my case, it's media files (TV recordings, music etc.), but still *way* too huge to be indexed on the client. Even attempting to do this is braindead (this is technical term, not an insult).

3.
Last, but most importantly, no program has the right to index all my drives without my *explicit* permission. Ask me, once. Give me a choice of which drives I want indexed, and where that index should be stored.
This can be dangerous. People regularly keep private stuff on a physical USB drive, for the explicit reason to not leave trails on the local computer - whatever reason they might have. Having metadata about files stored on a *different* drive (partition) is a privacy threat by its very nature and should never be done without explicit user approval.

This stuff is totally misguided and should be disabled RIGHT NOW, then fixed, then it can be enabled again.

Ben Bucksch (benbucksch) on 2014-08-25
tags: added: private
tags: added: freeze hang
tags: added: privacy
removed: private
Changed in gvfs (Debian):
status: Unknown → Confirmed
Andreas Hasenack (ahasenack) wrote :

Same here. If my disk LED is suddenly lit, I know what to kill. It's gvfsd-metadata.

Changed in gvfs (Debian):
status: Confirmed → Fix Released
thunderamur (thunderamur) wrote :

Waiting for fix release for Ubuntu 14.04

Valentas (vk-registrator) wrote :

When I work with images (generate, copy, move) and use nautilus gvfs-metadata often hangs Nautilus, so that it is not displaying any files in a window. Nautilus becomes fine when I kill gvfs-metadata. In my mind this is one of the most unfortunate recent features of Ubuntu.

Mihail (mihail-rozshko) wrote :

I have this gvfsd-metadata bug every day, before i get this bug in another package - mediascanner2.0.
Ubuntu 14.10 x86_64

Hermanus (hermanborsje) wrote :

Same here on Linux Mint 17.1. Bug keeps coming back :(

Krzysztof Dryja (cih997) wrote :

Any new fixes?

Bug still exists on Ubuntu 14.04.1 x86_64, gnome-shell 3.12, kernel 3.16.

Including frequent bug with upowerd (consuming 100% RAM) once a day in average I lose 100% RAM or CPU o_0

Are you guys talking about the issue on NFS filesystems or local disks?

There have been two independent issues, the NFS issue was fixed in around gvfs_1.17 while the other issue was fixed around gvfs_1.22.

NFS issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624507
local issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756205

Please make sure to use the latest upstream version of gvfs before filing any bug reports.

Petar Velkovski (pvelkovski) wrote :

John Paul Adrian Glaubitz (glaubitz) what use do I have that this bug might have been fixed around gvfs_1.22 when the Ubuntu 14.04.1 that I currently use uses gvfs (1.20.3-0ubuntu1) released 2015-02-02 and this bug is still present in it?!

For those that need a temporary fix for this bug, use the

sudo chmod -x /usr/lib/gvfs/gvfsd-metadata (makes gvfs-metadata non executable)

command, but be warned, after doing this nautilus tends to forget some settings and tweaks. For instance, on my computer, the desktop icons ( I have "show desktop icons" enabled) tend to be moved on the left side of the screen (in random order) on each system restart (this will definitely happen if you erased the file(s) in ~/.local/share/gvfs-metadata).

The "fix" can be reversed with

sudo chmod +x /usr/lib/gvfs/gvfsd-metadata (makes gvfs-metadata executable again).

Hard3D (xkebalx) wrote :

The same problem at 14.04, x64. However, I have traced the origin of this bug for me. I found that this bug begins to appear after I click on the video in the browser, right-click> Save frame as. After that, the picture is saved and there is an overload (devours ~ 40% CPU - I have four cores) - gvfsd have to kill the process. I watch a video in Firefox addon via "HTML5 Video Everywhere!". Now I just do not click on the button and do not face this problem.
If we consider that such GVFS, it is likely that some program, recording file causes a bug that produces an infinite loop command.
I think anyone with this bug occurs continuously, it is worth trying to observe and track its origin, and what causes it.

Philip J Reilly (pjpreilly) wrote :

This can be EASILY RECREATED with the Super Start 7.3.3 extension in Firefox.

Just right click on any tab to add to Super Start, click "Add this tab to Super Start" and the problem will occur in 12.04 as well as 14.04. In 14.04 the processor saturates 100%.

 In 12.04 the processor doesn't sat 100% but there is some kinda infinite disk activity.

Philip J Reilly (pjpreilly) wrote :

If Firefox is launched gksudo firefox in a terminal (superuser) Super Start has no problem with gvsfd-metadata in 12.04 or 14.04. There is apparently a privilege issue with this system call. This should be enough information to make considerable progress with this long standing bug. Unless the problem is INHERENT in the design. of course.

Ben Bucksch (benbucksch) wrote :

See the "remote bug watches" on the right here. It links to gnome-bugs #637095 <https://bugzilla.gnome.org/show_bug.cgi?id=637095> , which is FIXED.

Given that this bug can trash SSDs on hardware level, by making so many writes that the lifespan is considerably reduced, by doing billions of write calls in a matter of hours, I'm asking for a hotfix in Ubuntu 12.04 precise.

Given that SSDs are silent, a user wouldn't even notice this unless he has a CPU or disk meter or similar showing. I do, but I still missed this once and it ran for 10 hours overnight IIRC.

How can we escalate this for a hotfix in a stable distro? I don't know launchpad well enough. Could somebody please make some noise? There's already a straight-forward fix, and commited to the GNOME repo, it's just a matter of shipping it for the stable Ubuntu distros.

Philip J Reilly (pjpreilly) wrote :

Can somebody escalate the priority?

description: updated
Ben Bucksch (benbucksch) on 2015-03-08
description: updated
description: updated
Petar Velkovski (pvelkovski) wrote :

I would like to add that I don't think that the original bug reported with this bug report, is identical with the way this gvfs-metadata bug behaves in its later version as running rm -rf ~/.local/share/gvfs-metadata stops the infinite disk writing for just few minutes and that it starts again. Not only does it put the HDD under a strain (especially SSDs), it also kills the battery on laptop devices quicker especially when an ordinary HDD is used.

The finding that the bug is easily reproducible with the Super Start firefox extension is interesting. I'm using a similar extension on both my machines where this bug appears; it's Speed DIal [FWD] in my case. Some previous bug reports mention that the bug is triggered when using HTML5 Video Everywhere - another firefox plugin.

Is it possible that some of the libraries used by firefox produce files (or do something else) that than somehow confuse gvfs-metadata and force it to go into infinite writing loop?! If so, can this be also a firefox bug? Not that gvfs-metadata shouldn't be able to handle such situations.

Petar Velkovski (pvelkovski) wrote :

Also, I don;t think that the current incarnation of this bug is filling my HDD. When I open the ~/.local/share/gvfs-metadata folder in the file browser it is evident that a few files are constantly being generated and then erased ad nauseam. So there is no disk space eating problem, just the HDD (and laptop battery) straining problem.

Philip J Reilly (pjpreilly) wrote :

Can somebody confirm the Super Start recreation? The more the merrier!

Ben Bucksch (benbucksch) wrote :

Philip, the reproduction using Firefox has been investigated and confirmed to be a gvfs bug (not Firefox bug), and has already been FIXED (!) in the GNOME bug that I've been linking above.

This is just Ubuntu being inactive in shipping the fix.

Philip J Reilly (pjpreilly) wrote :

This has gotta be rampant in the world if it's happening in Firefox in any number of ways!

Philip J Reilly (pjpreilly) wrote :

We only can hope!

Philip,

when I said "Please make noise", I didn't meant that you should make 100
comments in the bug. I meant to raise awareness of the bug at the Ubuntu
maintainers who decide which hotfixes to include in a LTS release. I
don't know how that works.

Ben

Philip J Reilly wrote, On 08.03.2015 18:59:
> https://www.linuxliteos.com/forums/index.php?topic=1688.0
>

Philip J Reilly (pjpreilly) wrote :

Too noisy?

Philip J Reilly (pjpreilly) wrote :

Ben, I gave you an EASY way to recreate & test it! Just say thanks!

Ondrej Holy (oholy) wrote :

Hey all. I strongly advice (as an upstream gvfs maintainer) to apply mentioned patch from upstream Bug 637095 to fix problems with metadata:
https://bugzilla.gnome.org/show_bug.cgi?id=637095

There is several comments about several issues in this bug report, but the last comments are about this issue, which was fixed recently. However the mentioned upstream fix should be applied regardless this is correct bug report or not.

Philip J Reilly (pjpreilly) wrote :

I applied the patch to gvfs 1.20.3 on Linux Lite 2.2 (14.04l LTS) & it seems to fix the issue with Super Start Firefox extension.

Rainer Perske (perske) wrote :

This bug is severely trashing hardware. Please raise importance and make the bugfix of comment #49 available for 12.04 LTS. Thanks.

Finally I discovered, why my HDD makes a clicking noise, it was gvfs stuck in a loop (I am also using Super Start).

 Now I know why my live mint17.1 killed my flash drive. :(

Thanks again and raise awarnes.

The Bug 637095 is no longer available, where should we find a patch?

Vlad Orlov (monsta) wrote :

Huh... it seems to be that old bug that I've posted a patch for...
https://bugs.debian.org/756205#33

The debdiff will probably fail against Ubuntu version, so here's the original commit just in case:
https://git.gnome.org/browse/gvfs/commit/?id=23341281b7e7f3d92ea1f3d6dffc156a8adb03bc

tags: added: trusty
removed: 64bit freeze hang privacy
Vlad Orlov (monsta) on 2015-04-20
tags: added: utopic
Vlad Orlov (monsta) wrote :

How to reproduce the issue (and test if the patch works):
https://bugzilla.gnome.org/show_bug.cgi?id=637095#c47

Ben Bucksch (benbucksch) wrote :

> The Bug 637095 is no longer available, where should we find a patch?

Not the one here, but on gnome.
From comment #49:
> apply mentioned patch from upstream Bug 637095 to fix problems with metadata:
> https://bugzilla.gnome.org/show_bug.cgi?id=637095

-------

This must be backported to Precise (Ubuntu 12.04 LTS), too. Precise is still suported, and this is trashing hardware.

tags: added: hang precise
Vlad Orlov (monsta) wrote :

I'm not sure it'll be possible to backport the patch to Precise. The commit is from 1.20 branch, and Precise has 1.12...

Vlad Orlov (monsta) wrote :
Vlad Orlov (monsta) wrote :
Vlad Orlov (monsta) wrote :
Ben Bucksch (benbucksch) wrote :

Monsta wrote on 21.04.2015 12:47:
> ** Attachment added: "debdiff with the fix for Precise"
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/517021/+attachment/4380477/+files/gvfs-precise-debdiff

Thank you! :-)

What's the process of getting this into the release distro?

Vlad Orlov (monsta) wrote :

Well, I guess I'll need to write SRU Bug Template as well:

https://wiki.ubuntu.com/StableReleaseUpdates/#SRU_Bug_Template

The attachment "debdiff with the fix for Precise" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Fantu (fantonifabio) wrote :

Thanks mosta.

I think that in debdiff "Closes: #756205." should be replated by "(LP: #517021)" and UNRELEASED with name of release but probably are things that ubuntu-sponsors can do directly on commit.

Today I tested the patch in trusty, with it I'm unable to reproduce this bug and I not found any regression, seems ok.

Vlad Orlov (monsta) wrote :

Ah dammit, copy/paste error, this is the corresponding Debian bug number. :)

Thanks for pointing that out. Unfortunately, LP does not allow us to edit neither comments nor patches/debdiffs. I can only delete the attachments and upload the corrected ones. I'm not sure whether it should be done now since ubuntu-sponsors team is already subscribed to this report. Maybe they'll correct the bug number. If not, I can reupload the debdiffs.

As for the UNRELEASED thing, it's what the modern versions of dch put there when you run "dch --nmu" to indicate a non-maintainer upload. I didn't edit that afterwards.

Marc Deslauriers (mdeslaur) wrote :

Patch looks good, ACK. I've uploaded packages for precise, trusty and utopic with a slightly modified changelog for processing by the SRU team.

Thanks!

Changed in gvfs (Ubuntu Vivid):
status: Confirmed → Fix Released
Changed in gvfs (Ubuntu Precise):
status: New → In Progress
Changed in gvfs (Ubuntu Trusty):
status: New → In Progress
Changed in gvfs (Ubuntu Utopic):
status: New → In Progress
Vlad Orlov (monsta) wrote :

Thanks Marc :)

Hello mucku, or anyone else affected,

Accepted gvfs into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gvfs/1.20.3-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gvfs (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in gvfs (Ubuntu Utopic):
status: In Progress → Fix Committed
Chris J Arges (arges) wrote :

Hello mucku, or anyone else affected,

Accepted gvfs into utopic-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gvfs/1.20.2-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gvfs (Ubuntu Precise):
status: In Progress → Fix Committed
Chris J Arges (arges) wrote :

Hello mucku, or anyone else affected,

Accepted gvfs into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gvfs/1.12.1-0ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Philip J Reilly (pjpreilly) wrote :

Updated proposed globally & tested in Trusty using the Super Start add method. gvs-metadata remains sleeping & this update is confirmed as verification-done in Trusty.

Philip J Reilly (pjpreilly) wrote :

Updated proposed globally & tested in Precise using the Super Start add method. gvs-metadata remains sleeping & this update is confirmed as verification-done in Precise.

Fantu (fantonifabio) on 2015-04-30
tags: added: verification-done
removed: verification-needed
Petar Velkovski (pvelkovski) wrote :

I've installed gvfs 1.20.3-0ubuntu1.1 and other gvfs* packages with the same version that come with it from trusty-proposde under Trusty (Ubuntu 14.04) on both my PC and laptop and so far (second day of using it) I haven't been hit by this bug.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.12.1-0ubuntu1.3

---------------
gvfs (1.12.1-0ubuntu1.3) precise; urgency=low

  * debian/patches/avoid-endless-looping.patch: picked from upstream.
    Fixes constant disk usage in certain situations. (LP: #517021)

 -- Vlad Orlov <email address hidden> Tue, 21 Apr 2015 11:21:06 +0300

Changed in gvfs (Ubuntu Precise):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for gvfs has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Fantu (fantonifabio) wrote :

Why is itn't pushed to -updates for trusty?

tags: added: verification-done-trusty
Vlad Orlov (monsta) wrote :

I have the same question as Fantu. Why? :-/

Fantu (fantonifabio) wrote :

Seems that is blocked because cause a regression (found with auto tests):
https://jenkins.qa.ubuntu.com/job/trusty-adt-gvfs/lastBuild/
I not tested the official proposed packages but another I did with the same patch before and is ok
Someone have tested the official proposed instead?

Launchpad Bug Tracker wrote on 06.05.2015 20:01:
> ** Changed in: gvfs (Ubuntu Precise)
> Status: Fix Committed => Fix Released

Fix tested and confirmed in Ubuntu 12.04 Precise.

Before, I reproducibly ran into this bug when saving a data: URL from a
Firefox-based webapp to a local file using the normal Firefox download
dialog.

I installed the Precise update from the normal Precise update package
repositories.

I save now, and I do not see the 100% CPU usage anymore. Bug fixed.

Thanks a lot to Ross Lagerwall,Tomas Bzate, Alexander Larsson, Ondrej
Holy (all GNOME <https://bugzilla.gnome.org/show_bug.cgi?id=637095>),
Monsta, Marc Deslauriers (here) and everybody else involved!

Fantu (fantonifabio) wrote :

Autopkgtest seems still mark release for trusty as cause of regression :(
http://people.canonical.com/~ubuntu-archive/pending-sru.html

tags: added: verification-needed
removed: verification-done
Changed in gvfs:
importance: Unknown → Medium
status: Unknown → Fix Released
tags: added: verification-done-precise verification-needed-utopic
removed: hang verification-needed
Vlad Orlov (monsta) wrote :

Would be nice to know the details of that "regression" as well.

Vlad Orlov (monsta) wrote :

The only error message I could find in the logs is this:

Error: Did not find a parent process that runs as non-root

at https://jenkins.qa.ubuntu.com/job/trusty-adt-gvfs/ARCH=amd64,label=adt/152/

What's going on? It seems like internal error on build server, not a regression in gvfs.

Iain Lane (laney) wrote :

Don't know what's going on for trusty. SRU team: could you please release? The autopkgtest failures don't look related.

tags: added: verification-done-utopic
removed: verification-needed-utopic
Chris Halse Rogers (raof) wrote :

Indeed, that looks like an test environment failure. :(

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.20.3-0ubuntu1.1

---------------
gvfs (1.20.3-0ubuntu1.1) trusty; urgency=medium

  * debian/patches/avoid-endless-looping.patch: picked from upstream.
    Fixes constant disk usage in certain situations. (LP: #517021)

 -- Vlad Orlov <email address hidden> Tue, 21 Apr 2015 12:45:17 +0300

Changed in gvfs (Ubuntu Trusty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.20.2-1ubuntu3.1

---------------
gvfs (1.20.2-1ubuntu3.1) utopic; urgency=medium

  * debian/patches/avoid-endless-looping.patch: picked from upstream.
    Fixes constant disk usage in certain situations. (LP: #517021)

 -- Vlad Orlov <email address hidden> Tue, 21 Apr 2015 13:27:03 +0300

Changed in gvfs (Ubuntu Utopic):
status: Fix Committed → Fix Released
Vlad Orlov (monsta) wrote :

Thanks!

Frogs Hair (detaill) wrote :

Ubuntu 16.04 beta 1 also affected

Vlad Orlov (monsta) wrote :

Weird - it should not happen anymore since the fix is in upstream versions since 1.22.

Ubuntu 16.04 LTS also with the same problem here.

Philip J Reilly (pjpreilly) wrote :

This is bad, very bad.

[UPDATE]

Here the problem persists. Ubuntu 16.04 LTS.

Tried the solution of emptying the metadata folder described above and it eliminates the mentioned problem for just a few days. Done this a couple of times.

Now, i am trying the other proposed solution above of disabling gvfsd: "chmod -x /usr/lib/gvfs/gvfsd-metadata".

Waiting for a fix.

Best regards

We have the same issue on 16.04 LTS with several systems using cinnamon. It seems to hang on the cifs mounted network share, 1tb + and a million + files for some users.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.