GNOME Bugzilla – Bug 763394
gvfsd-trash 50% cpu usage for minutes, even hours after trashing many files
Last modified: 2016-06-06 12:21:53 UTC
After deleting many files with the `trash` command cpu usage of gvfsd-trash jumps to 50% and stays there. With the following bash script I could reproduce this in all of the cases I ran that script: cd /tmp && mkdir test && cd /tmp/test && for ((i=0;i<2000;i++)); do touch "$i.tmp"; done && trash /tmp/test/*.tmp With this script I could reproduce the high cpu usage for some minutes, but only two times. Currently that script won't result in the bug anymore ... It's kind of magic. One time when that bug still wasn't routine to me, I had that high cpu usage for 4+ hours. When the above script lead to the high cpu usage my syslog was spammed with these errors: Morg.gtk.vfs.Daemon[30054]: Error calling org.gtk.vfs.MonitorClient.Changed(): No such interface 'org.gtk.vfs.MonitorClient' on object at path /org/gtk/vfs/client/filemonitor/13 (g-dbus-error-quark, 19) Morg.gtk.vfs.Daemon[30054]: ** (process:30356): WARNING **: send_infos_cb: The connection is closed (g-io-error-quark, 18) Morg.gtk.vfs.Daemon[30054]: ** (process:30356): WARNING **: send_done_cb: The connection is closed (g-io-error-quark, 18) When gvfsd-trash hangs killing it several times works. For some reason 1 or maybe 4 times pkill gvfsd-trash doesn't work. I just spam it roughly 10 times in some terminal. That's why I can't give an exact number.
Btw: trashing 2000 files seems theoretical, but I have this bug regularly when using FreeFileSync, which moves files to trash, if configured to do so, instead of directly deleting them.
(In reply to xyzdragon from comment #0) > (snap) > > With this script I could reproduce the high cpu usage for some minutes, but > only two times. Currently that script won't result in the bug anymore ... > It's kind of magic. Thanks for your bug report. I suppose that you can reproduce this bug only when nautilus is running, am I right?
Actually I'm using xfce 4.12.2 and thunar 1.6.10-2, sorry for not mentioning this. Closing thunar still will lead to that bug, even though I won't get the above spamming of warnings and errors anymore. So there is even less to go on. ~/.xsession-errors and /var/log/debug don't have anything useful either. Another note. pkill gvfsd-trash won't result in any unwanted sideeffects, meaning the files are already deleted and killing gvfsd-trash won't change that. Is there any way I can find out in which subfunction gvfsd-trash hangs? like with gdb? Maybe it's trying to get some stats on my overfull trash and that is what takes so long? Note also that the `trash` command is finished in the shell. I also have the problem, that a manual delete on trash very often takes minutes to hours, that's why I have to lowlevel 'rm ~/.trash' more ofthen than using the normal'empty trash' command ...
Lastly. When gvfsd-trash is at 25%, xfdesktop also uses 15%, I'm thinking because I have the trash-icon on my desktop ... ?
Created attachment 323682 [details] gvfsd-trash-cpu-usage-conky When creating this screenshot I noticed that my desktop (xfdesktop) is unclickable with that bug. My guess is that xfdesktop tries to query gvfsd-trash whether the trash is full or not in order to display the correct icon, and gvfsd-trash begins to make a full stat of my trash, which for some reason takes aeons for 10k+ files.
'rm' -r ~/.local/share/Trash/ ends the high cpu usage and my desktop also refreshes again
Hmm, yes, it is probably caused by the xfdesktop, which reloads icon on each change, which causes high cpu load, when trashing big amount of files... I am pretty sure this is the same problem as mentioned in Bug 763218, however it needs to be fixed in xfdesktop probably, but marking as duplicate for know.. *** This bug has been marked as a duplicate of bug 763218 ***
The resolved patch involves unexpectedly nautilus instead of gvfsd-trash. I'm using Thunar. Am I to file another bug at xfce.bugzilla.org?
I am sorry, I forgot on this bug. Yes please, fill bug against xfdesktop. G_FILE_ATTRIBUTE_TRASH_ITEM_COUNT has to be used instead of enumeration...