Package: gvfs-daemons
Version: 1.12.3-4
Severity: serious
Tags: fixed-upstream fixed-in-experimental
Thanks
Since hours gvfsd-metadata eats my cpu. It is running four times
PID TTY TIME CMD
4570 ? 00:00:00 gvfsd-metadata
5068 ? 00:00:00 gvfsd-metadata
5816 ? 00:00:00 gvfsd-metadata
11843 ? 02:46:12 gvfsd-metadata
The is true for gvfsd. How can this happen?
And obviously the last one went crazy
PID PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11843 20 0 9060 416 416 R 94,4 0,1 167:41.82 gvfsd-metadata
# ps -C gvfsd
PID TTY TIME CMD
4302 ? 00:00:00 gvfsd
4537 ? 00:00:00 gvfsd
4547 ? 00:00:00 gvfsd
4559 ? 00:00:00 gvfsd
11832 ? 00:00:00 gvfsd
As gvfs is part of the libarchive transition, the upgrade to 1.16 is
held in experimental. Please increase the urgency and apply patches
in #596054 and #677430. It seems this is the same occurance of #624507
and can be merged.
The changelog shows, this is fixed in 1.16 [1]
gvfs (1.16.2-1) experimental; urgency=low
* New upstream release.
* Refresh patches to apply cleanly:
- debian/patches/06_metadata_nfs.patch
- debian/patches/dont-crash-on-null-job.patch
- debian/patches/metadata-dont-flush-null-tree.patch
- debian/patches/metadata-nuke-junk-data.patch
- debian/patches/ref-jobs-in-thread.patch
I use awesome wm and am not in the need of gvfsd, but evince and
libglib2.0-0, which is required by libgtk2.0-0, claws-mail, libreoffice
and LOTS more, depend on it. I want to be able, to disable it
(#544148). Thanks!
Loaded symbols for /usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
apply_journal_to_builder (builder=0x8073448, tree=0x8067e58) at
metatree.c:2287 2287 metatree.c: No such file or directory.
$ apt-file search metatree.c
<no output>
(gdb) bt
#1 meta_tree_flush_locked (tree=tree@entry=0x8067e58) at metatree.c:2357
#2 0x0804fcd1 in meta_tree_flush (tree=0x8067e58) at metatree.c:2375
#3 0x0804b813 in writeout_timeout (data=data@entry=0x80710e8) at
meta-daemon.c:62
#4 0xb7d530a7 in g_timeout_dispatch (source=source@entry=0x806f958,
callback=0x804b800 <writeout_timeout>,
user_data=0x80710e8) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:4413
#5 0xb7d52353 in g_main_dispatch (context=0x806b3f0) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3054
#6 g_main_context_dispatch (context=context@entry=0x806b3f0) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3630
#7 0xb7d526f0 in g_main_context_iterate (context=0x806b3f0,
block=block@entry=1, dispatch=dispatch@entry=1,
self=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
at /build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3701
#8 0xb7d52bcb in g_main_loop_run (loop=loop@entry=0x806b910) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3895
#9 0x0804b68e in main (argc=1, argv=0xbffff544) at meta-daemon.c:818
(gdb) frame 1
#1 meta_tree_flush_locked (tree=tree@entry=0x8067e58) at
metatree.c:2357 2357 in metatree.c
(gdb) print tree
$1 = (MetaTree *) 0x8067e58
(gdb) frame 3
#3 0x0804b813 in writeout_timeout (data=data@entry=0x80710e8) at
meta-daemon.c:62
62 meta-daemon.c: Datei oder Verzeichnis nicht gefunden.
(gdb) print data
$2 = (gpointer) 0x80710e8
(gdb) frame 4
#4 0xb7d530a7 in g_timeout_dispatch (source=source@entry=0x806f958,
callback=0x804b800 <writeout_timeout>,
user_data=0x80710e8) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:4413
4413 /build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c: Datei oder
Verzeichnis nicht gefunden.
(gdb) print source
$3 = (GSource *) 0x806f958
(gdb) frame 5
#5 0xb7d52353 in g_main_dispatch (context=0x806b3f0) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3054
3054 in /build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c
(gdb) print context
$4 = (GMainContext *) 0x806b3f0
(gdb) frame 6
#6 g_main_context_dispatch (context=context@entry=0x806b3f0) at
/build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c:3630
3630 in /build/glib2.0-Q0IaBZ/glib2.0-2.36.3/./glib/gmain.c
(gdb) print context
$5 = (GMainContext *) 0x806b3f0
This is interesting but helps no further. I am thrown to the dangerous
depths of the internet and found some desperate ubuntu users [2]
<
It looks like your metadata store is got corrupted, leading to an
infinite loop in the code.
FIX:
The fix here is to remove the metadata storage, located in:
~/.local/share/gvfs-metadata.
>
Done this.
$ GVFS=~/.local/share/gvfs-metadata; find $GVFS; rm -r $GVFS
/home/kardan/.local/share/gvfs-metadata
/home/kardan/.local/share/gvfs-metadata/root-8d18146e.log
/home/kardan/.local/share/gvfs-metadata/uuid-01050e0a-03a3-4805-825f-149b49691cca
/home/kardan/.local/share/gvfs-metadata/uuid-eec4f892-2cc8-4447-81d2-910b3ff061f2
/home/kardan/.local/share/gvfs-metadata/uuid-01050e0a-03a3-4805-825f-149b49691cca-15c60c55.log
/home/kardan/.local/share/gvfs-metadata/root-6418c987.log
/home/kardan/.local/share/gvfs-metadata/uuid-eec4f892-2cc8-4447-81d2-910b3ff061f2-af3df957.log
/home/kardan/.local/share/gvfs-metadata/home
/home/kardan/.local/share/gvfs-metadata/root
/home/kardan/.local/share/gvfs-metadata/home-94c2b285.log
/home/kardan/.local/share/gvfs-metadata/uuid-d0da3810-f16b-4cd8-9f0f-387439e71e99
/home/kardan/.local/share/gvfs-metadata/uuid-d0da3810-f16b-4cd8-9f0f-387439e71e99-c1d55111.log
/home/kardan/.local/share/gvfs-metadata/home-ffd7055e.log
$ pkill gvfsd-metadata
I waited a bit, to let it normalize and indeed after 5 minutes my fan
stopped.
< https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/517021
> > 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
< https://bugzilla.gnome.org/show_bug.cgi?id=637095
> Great, thanks for the review! Committed all the above, with
> corrections.
kardan
2]
http://ftp-master.metadata.debian.org/changelogs//main/g/gvfs/gvfs_1.16.2-2_changelog
3] http://ubuntuforums.org/showthread.php?t=1421580
ii gvfs:i386 1.12.3-4
ii gvfs-daemons 1.12.3-4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
