Xfce Forum

jeff story

Member

From: Shelton, WA, USA

Registered: 2011-05-09

Posts: 32

Website

'gvfsd-trash' Journal Spam [work around for now]

I'm running Arch with latest Xfce and Gnome's gvfs for managing trash service.

For well over a year, the journals in several Arch installs I'm running have been getting spammed with a slight variation of following:

Apr 02 11:21:43 Arch2024p8 gvfsd-trash[1139]: file ../glib/gio/gfileinfo.c: line 1698 (g_file_info_get_name): should not be reached
Apr 02 11:21:43 Arch2024p8 gvfsd-trash[1139]: GFileInfo created without standard

I'm not talking a few messages, but anywhere from 300 to 600 repeats directly following a reboot, with additional groups over time.
These groups usually have the same timestamp down to the second. This error seems to be nothing new, and I've read more than one bug report over time.

So today I decided waiting for a fix was no longer an option, and dove in to figuring out a fix or at least reducing the amount of spam.
I believe I've made some progress, but lack any knowledge of C to go much further...

I initially tried to block the messages from being logged using a /etc/systemd/journald.conf.d/gvfs-filter.conf file with several variations based on this info:

$ journalctl -b -o json | grep -m 1 'GFileInfo created without standard::name'  | jq .

{
  "_GID": "1000",
  "_RUNTIME_SCOPE": "system",
  "__REALTIME_TIMESTAMP": "1743622803765113",
  "__SEQNUM_ID": "1f8da28b925b490cbcaa0ccd79792f74",
  "_PID": "1154",
  "_TRANSPORT": "journal",
  "_SYSTEMD_OWNER_UID": "1000",
  "_COMM": "gvfsd-trash",
  "_SYSTEMD_INVOCATION_ID": "a1b82fb97a244206a9a7e31eb78237bc",
  "_SYSTEMD_SLICE": "user-1000.slice",
  "_SYSTEMD_USER_SLICE": "session.slice",
  "_SYSTEMD_CGROUP": "/user.slice/user-1000.slice/user@1000.service/session.slice/gvfs-daemon.service",
  "_AUDIT_SESSION": "2",
  "MESSAGE": "GFileInfo created without standard::name",
  "_CAP_EFFECTIVE": "0",
  "PRIORITY": "4",
  "_HOSTNAME": "Arch2024p8",
  "_SYSTEMD_USER_UNIT": "gvfs-daemon.service",
  "GLIB_DOMAIN": "GLib-GIO",
  "_BOOT_ID": "14030a9adf374d91abd5645bb35d9036",
  "_CMDLINE": "/usr/lib/gvfsd-trash --spawner :1.6 /org/gtk/gvfs/exec_spaw/0",
  "_MACHINE_ID": "f895580536ac47769712a37b5eab8c71",
  "_SOURCE_REALTIME_TIMESTAMP": "1743622803765089",
  "_AUDIT_LOGINUID": "1000",
  "__MONOTONIC_TIMESTAMP": "26916858",
  "_SYSTEMD_UNIT": "user@1000.service",
  "__SEQNUM": "7160",
  "_UID": "1000",
  "GLIB_OLD_LOG_API": "1",
  "__CURSOR": "s=1f8da28b925b490cbcaa0ccd79792f74;i=1bf8;b=14030a9adf374d91abd5645bb35d9036;m=19ab7fa;t=631d0d1d73779;x=bd243ba3bba9f3cd",
  "_EXE": "/usr/lib/gvfsd-trash"
}

Tried using one or a combination of variations of the following, '_UID=1000, pasting the errors to block, etc, with all having no effect.
This was the last attempt that was ignored.

[Journal]
Suppress=PRIORITY=4 _COMM=gvfsd-trash

Next I focused on the journals config to set 'RateLimitInterval' and 'SecRateLimitBurst' settings via /etc/systemd/journald.conf.d/journald.conf.

Manipulating these settings had an obvious effect on several programs with the following in the journal:  'systemd-journald[388]: [🡕] Suppressed 10 messages from <blocked app>'. What's odd is this message was never displayed for gvfs-trash, even when the spam was absent with the 'RateLimitInterval' and 'SecRateLimitBurst' set to 1. Of course I don't want to kill all the useful journal logging with these settings, as these settings were only part of testing.

However, unless the config was set to something ridiculously low: ie  'RateLimitInterva=1'  'SecRateLimitBurst=2' the settings had little influence on the gvfsd-trash spam.

A strace of gvfs-trash resulted in the following. I think possibly the,

sendmsg(12, {msg_name={sa_family=AF_UNIX, sun_path="/run/systemd/journal/socket"}....

from gvfs-trash may be bypassing the normal method of writing to the journal. This would explain the "spam Rate and Burst limits having no effect on gvfs-trash when set at reasonable values.

3181  newfstatat(AT_FDCWD, "/home/jeff/.local/share/Trash/files", {st_mode=S_IFDIR|0700, st_size=143360, ...}, 0) = 0

3181  statx(AT_FDCWD, "/home/jeff/.local/share/Trash/files/Error-Output", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, 
	STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=1292, ...}) = 0

3181  sendmsg(12, {msg_name={sa_family=AF_UNIX, sun_path="/run/systemd/journal/socket"}, msg_namelen=29, 
	msg_iov=[{iov_base="GLIB_OLD_LOG_API", iov_len=16}, {iov_base="=", iov_len=1}, {iov_base="1", iov_len=1}, 
	{iov_base="\n", iov_len=1}, {iov_base="MESSAGE", iov_len=7}, {iov_base="=", iov_len=1}, 
	{iov_base="GFileInfo created without standa"..., iov_len=40}, {iov_base="\n", iov_len=1}, 
	{iov_base="PRIORITY", iov_len=8}, {iov_base="=", iov_len=1}, {iov_base="4", iov_len=1}, {iov_base="\n", iov_len=1}, 
	{iov_base="GLIB_DOMAIN", iov_len=11}, {iov_base="=", iov_len=1}, {iov_base="GLib-GIO", iov_len=8}, 
	{iov_base="\n", iov_len=1}], msg_iovlen=16, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 100

3181  sendmsg(12, {msg_name={sa_family=AF_UNIX, sun_path="/run/systemd/journal/socket"}, 
	msg_namelen=29, msg_iov=[{iov_base="GLIB_OLD_LOG_API", iov_len=16}, {iov_base="=", iov_len=1}, {iov_base="1", iov_len=1}, 
	{iov_base="\n", iov_len=1}, {iov_base="MESSAGE", iov_len=7}, {iov_base="=", iov_len=1}, 
	{iov_base="file ../glib/gio/gfileinfo.c: li"..., iov_len=85}, {iov_base="\n", iov_len=1}, {iov_base="PRIORITY", iov_len=8}, 
	{iov_base="=", iov_len=1}, {iov_base="4", iov_len=1}, {iov_base="\n", iov_len=1}, {iov_base="GLIB_DOMAIN", iov_len=11}, 
	{iov_base="=", iov_len=1}, {iov_base="GLib-GIO", iov_len=8}, {iov_base="\n", iov_len=1}], msg_iovlen=16, msg_controllen=0, msg_flags=0}, 
	MSG_NOSIGNAL) = 145

3181  access("/home/jeff/.local/share/Trash/files", W_OK) = 0 

The strace output also contained many permission related messages:

3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/libsubcmd-in.o") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/exec-cmd.o") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/.exec-cmd.o.cmd") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/help.o") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/.help.o.cmd") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/pager.o") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/.pager.o.cmd") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/parse-options.o") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/.parse-options.o.cmd") = -1 EACCES (Permission denied)
3603  unlink("/home/jeff/.local/share/Trash/expunged/472992807/tools/objtool/libsubcmd/run-command.o") = -1 EACCES (Permission denied)

The permission related data also has me questioning how I use trash. On a storage limited system, I try to keep the trash free from large files and dirs, for example building kernels for testing. I'll delete files/dir's in Thunar, then open the trash icon and selectively delete any large files/dir's. This is rather than using the 'empty trash' selection. Perhaps I'm abusing the trash management and creating permission issues by doing this?

That said, what are people using for trash management?

I'm even contemplating rsyslog as a journalctl replacement at this point, although seems way overkill just to get rid of log spam.

If it's verified that gvfs-trash is intentionally spamming logs through bypassing the normal journal writing protocol, I want nothing to do with it, and will need an alternative.

--------------------------------------------------------------------------------------------------------
A new post next day below..... Added later 20 h 34 min 08 s:
-------------------------------------------------------------------------------------------------------

I made some progress on this and have some additional info to share.

It seems for every entry in the trash, a pair of messages is spammed to the journal. My earlier question about deleting individual files from within trash has no effect.

There were some packages in Arch's testing repo this morning that I also thought were involved (seems gio's the source of the messages). IIRC, one of them even had a fix specifically for gvfs-trash. Unfortunately, installing them didn't fix the spam... Maybe a fix coming in the next gvfs release?

Next I considered a workaround an acceptable solution at this point. After all, everything seems to be working just fine and it's only the journal spam that's bothering me.

That said, in the end I did succeed in removing the spam from the journal. For anyone considering duplicating my efforts..... read on.

------------------------------------------------------------------------------------------------------------------
  WORKAROUND:
------------------------------------------------------------------------------------------------------------------

Create a user service file with the following content:

sudo <editor> /usr/lib/systemd/user/gvfsd-trash.service	

       

[Unit]
Description=GVFS Trash Service

[Service]
ExecStart=/usr/lib/gvfsd-trash
StandardError=file:/home/<User-Name>/.local/share/Trash/gvfsd-trash.log
StandardOutput=file:/home/<User-Name>/.local/share/Trash/gvfsd-trash.log

[Install]
WantedBy=default.target

Enable the newly created user service:

systemctl --user enable gvfsd-trash.service

Reboot

Check, make sure the service is running properly:

systemctl --user status gvfsd-trash.service

Also check the journal and the new /home/<User-Name>/.local/share/Trash/gvfsd-trash.log

journalctl -b | grep gvfsd-trash
cat /home/<User-Name>/.local/share/Trash/gvfsd-trash.log

I also plan on supplementing this workaround with a script to monitor the size of the new gvfsd-trash.log file and delete it after a size or lines limit is met.

Last edited by jeff story (2025-04-08 04:24:16)

---

aka Cody_Learner https://github.com/Cody-Learner

eriefisher

Wanderer

From: ON, Canada

Registered: 2008-10-25

Posts: 761

Re: 'gvfsd-trash' Journal Spam [work around for now]

What version of gvfs are you using and do you have all the associated packages installed?

---

I AM CANADIAN!
Siduction
Debian Sid
Xfce 4.20 with Wayland/Labwc

jeff story

Member

From: Shelton, WA, USA

Registered: 2011-05-09

Posts: 32

Website

Re: 'gvfsd-trash' Journal Spam [work around for now]

I'm running Arch Linux with current Xfce in xorg and:

xfce 4.20
gvfs 1.57.2-2
glib2 2.84.1-1
linux-stable-rc 6.13.10rc-1

EDIT: 2025-04-07 Additional Info

Anyone looking for a solution, see WORKAROUND: in the wall of text top post.
Based on the lack of progress in the bug reports below, I'm not expecting an upstream fix anytime soon.

https://gitlab.gnome.org/GNOME/gvfs/-/issues/606
https://gitlab.gnome.org/GNOME/gvfs/-/issues/777

Archlinux, xfce
glib2 2.82.4-2
gvfs 1.56.1-2
linux 6.12.10.arch1-1

Issue created 3 months ago
0 Assignees None

Last edited by jeff story (2025-04-08 04:22:12)

---

aka Cody_Learner https://github.com/Cody-Learner