gvfsd-metadata causes 100% CPU usage
| 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:/
--- 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 : | #1 |
| Changed in gvfs (Ubuntu): | |
| assignee: | nobody → Ubuntu Desktop Bugs (desktop-bugs) |
| importance: | Undecided → Medium |
| status: | New → Incomplete |
| mucku (dereinsameberg) wrote : | #2 |
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 : | #3 |
Pressing F5 in a folder to refresh its contents seems to invoke "gvfsd-metadata". Whatever it does.
| Donny Kurnia (donnykurnia) wrote : | #4 |
In my system, this bug is happened when I copy or move files from one folder to another.
| Gorka Navarrete (emrys) wrote : | #5 |
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 : | #6 |
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[
[ 181.933416] gvfsd-metadata[
[ 214.045839] gvfsd-metadata[
[ 246.264777] gvfsd-metadata[
[ 278.625348] gvfsd-metadata[
[ 310.613414] gvfsd-metadata[
[ 342.741799] gvfsd-metadata[
[ 374.813577] gvfsd-metadata[
[ 407.074920] gvfsd-metadata[
[ 817.351735] gvfsd-metadata[
[ 854.474189] gvfsd-metadata[
[ 895.449230] gvfsd-metadata[
[ 899.975967] modplug0:
[ 912.824717] modplug0:
| mucku (dereinsameberg) wrote : | #7 |
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 : | #8 |
My disk space was really full at one moment, no byte left free. People say, that does corrupt the files in the ~/.local/
| mucku (dereinsameberg) wrote : | #9 |
Wow, that tip with
rm -rf ~/.local/
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 : | #10 |
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 : | #11 |
Yes, mucku
Your solution worked in my laptop. It seems that ~/.local/
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.
| description: | updated |
| Changed in gvfs (Ubuntu): | |
| status: | Incomplete → New |
| Changed in gvfs (Ubuntu): | |
| status: | New → Fix Released |
| Vladimir (vladimir-kozlov) wrote : | #12 |
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/
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 : | #13 |
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 : | #14 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in gvfs (Ubuntu): | |
| status: | New → Confirmed |
| Ben Hall (bhall-f) wrote : | #15 |
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 : | #16 |
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.
| Manuel Iglesias Alonso (glesialo) wrote : | #17 |
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/
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://
Fedora/RHEL: https:/
GNOME (upstream): https:/
Cheers,
Adrian
| Nicola Larosa (teknico) wrote : | #19 |
This happened to me today. Same problem, same workaround.
| Paul Sokolovsky (pfalcon) wrote : | #20 |
Brave guy at http://
| Moses Moore (moses-mozai) wrote : | #21 |
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/
| Galen Thurber (godfree2) wrote : | #22 |
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/
| isync (o-zucker) wrote : | #24 |
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/
| Ben Bucksch (benbucksch) wrote : | #25 |
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.
| tags: | added: private |
| tags: | added: freeze hang |
| tags: |
added: privacy removed: private |
| Changed in gvfs (Debian): | |
| status: | Unknown → Confirmed |
| Andreas Hasenack (ahasenack) wrote : | #26 |
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 : | #27 |
Waiting for fix release for Ubuntu 14.04
| Valentas (vk-registrator) wrote : | #28 |
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 : | #29 |
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 : | #30 |
Same here on Linux Mint 17.1. Bug keeps coming back :(
| Krzysztof Dryja (cih997) wrote : | #31 |
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://
local issue: https:/
Please make sure to use the latest upstream version of gvfs before filing any bug reports.
| Petar Velkovski (pvelkovski) wrote : | #33 |
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/
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/
The "fix" can be reversed with
sudo chmod +x /usr/lib/
| Hard3D (xkebalx) wrote : | #34 |
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 : | #35 |
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 : | #36 |
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 : | #37 |
See the "remote bug watches" on the right here. It links to gnome-bugs #637095 <https:/
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 : | #38 |
Can somebody escalate the priority?
| description: | updated |
| description: | updated |
| description: | updated |
| Petar Velkovski (pvelkovski) wrote : | #39 |
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/
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 : | #40 |
Also, I don;t think that the current incarnation of this bug is filling my HDD. When I open the ~/.local/
| Philip J Reilly (pjpreilly) wrote : | #41 |
Can somebody confirm the Super Start recreation? The more the merrier!
| Ben Bucksch (benbucksch) wrote : | #42 |
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 : | #43 |
This has gotta be rampant in the world if it's happening in Firefox in any number of ways!
| Philip J Reilly (pjpreilly) wrote : | #45 |
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:/
>
| Philip J Reilly (pjpreilly) wrote : | #47 |
Too noisy?
| Philip J Reilly (pjpreilly) wrote : | #48 |
Ben, I gave you an EASY way to recreate & test it! Just say thanks!
| Ondrej Holy (oholy) wrote : | #49 |
Hey all. I strongly advice (as an upstream gvfs maintainer) to apply mentioned patch from upstream Bug 637095 to fix problems with metadata:
https:/
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 : | #50 |
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 : | #51 |
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 : | #54 |
Huh... it seems to be that old bug that I've posted a patch for...
https:/
The debdiff will probably fail against Ubuntu version, so here's the original commit just in case:
https:/
| tags: |
added: trusty removed: 64bit freeze hang privacy |
| tags: | added: utopic |
| Vlad Orlov (monsta) wrote : | #55 |
How to reproduce the issue (and test if the patch works):
https:/
| Ben Bucksch (benbucksch) wrote : | #56 |
> 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:/
-------
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 : | #57 |
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 : | #58 |
| Vlad Orlov (monsta) wrote : | #59 |
| Vlad Orlov (monsta) wrote : | #60 |
| Ben Bucksch (benbucksch) wrote : | #61 |
Monsta wrote on 21.04.2015 12:47:
> ** Attachment added: "debdiff with the fix for Precise"
> https:/
Thank you! :-)
What's the process of getting this into the release distro?
| Vlad Orlov (monsta) wrote : | #62 |
Well, I guess I'll need to write SRU Bug Template as well:
https:/
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 : | #64 |
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 : | #65 |
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 : | #66 |
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 : | #67 |
Thanks Marc :)
Hello mucku, or anyone else affected,
Accepted gvfs into trusty-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| 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 : | #69 |
Hello mucku, or anyone else affected,
Accepted gvfs into utopic-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| Changed in gvfs (Ubuntu Precise): | |
| status: | In Progress → Fix Committed |
| Chris J Arges (arges) wrote : | #70 |
Hello mucku, or anyone else affected,
Accepted gvfs into precise-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| Philip J Reilly (pjpreilly) wrote : | #71 |
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 : | #72 |
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.
| tags: |
added: verification-done removed: verification-needed |
| Petar Velkovski (pvelkovski) wrote : | #73 |
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 : | #74 |
This bug was fixed in the package gvfs - 1.12.1-0ubuntu1.3
---------------
gvfs (1.12.1-0ubuntu1.3) precise; urgency=low
* debian/
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 : | #76 |
Why is itn't pushed to -updates for trusty?
| tags: | added: verification-done-trusty |
| Vlad Orlov (monsta) wrote : | #77 |
I have the same question as Fantu. Why? :-/
| Fantu (fantonifabio) wrote : | #78 |
Seems that is blocked because cause a regression (found with auto tests):
https:/
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:/
Monsta, Marc Deslauriers (here) and everybody else involved!
| Fantu (fantonifabio) wrote : | #80 |
Autopkgtest seems still mark release for trusty as cause of regression :(
http://
| 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 : | #81 |
Would be nice to know the details of that "regression" as well.
| Vlad Orlov (monsta) wrote : | #82 |
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:/
What's going on? It seems like internal error on build server, not a regression in gvfs.
| Iain Lane (laney) wrote : | #83 |
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 : | #84 |
Indeed, that looks like an test environment failure. :(
| Launchpad Janitor (janitor) wrote : | #85 |
This bug was fixed in the package gvfs - 1.20.3-0ubuntu1.1
---------------
gvfs (1.20.3-0ubuntu1.1) trusty; urgency=medium
* debian/
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 : | #86 |
This bug was fixed in the package gvfs - 1.20.2-1ubuntu3.1
---------------
gvfs (1.20.2-1ubuntu3.1) utopic; urgency=medium
* debian/
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 : | #87 |
Thanks!
| Frogs Hair (detaill) wrote : | #88 |
Ubuntu 16.04 beta 1 also affected
| Vlad Orlov (monsta) wrote : | #89 |
Weird - it should not happen anymore since the fix is in upstream versions since 1.22.
| Victor Rodrigues (vicerodrigues) wrote : | #90 |
Ubuntu 16.04 LTS also with the same problem here.
| Philip J Reilly (pjpreilly) wrote : | #91 |
This is bad, very bad.
| Victor Rodrigues (vicerodrigues) wrote : | #92 |
[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/
Waiting for a fix.
Best regards
| Machiel van Veen (machielvanveen) wrote : | #93 |
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.


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