gvfsd doesn't start gvfsd-admin when needed.

Issues related to applications and software problems
Post Reply
Spork Schivago
Posts: 37
Joined: 2017/08/14 04:21:54

gvfsd doesn't start gvfsd-admin when needed.

Post by Spork Schivago » 2018/02/08 23:43:24

From the man pages of gvfsd, I see:

Code: Select all

...
The primary task of gvfsd is to act as a mount tracker/manager. It spawns new backends when requested and keeps track fo their lifecycle, maintaining a list of active mounts and creates direct connections to them.
...
So to me, I take this to mean that gvfsd is responsible for starting the backends, when requested. Is this correct?

On my system, if I start a program like Nautilus or Gedit and try to use the admin backend by opening a file or directory using the admin:// prefix, gvfsd does not start gvfsd-admin and eventually, the process times out. With GEdit, I get an error message stating that the admin:///<filename> couldn't be opened.

With Nautilus, it'll open an empty window and the task bar at the bottom of my screen shows Loading....and then just disappears after a while and nothing happens.

If I manually start gvfsd-admin:

Code: Select all

pkexec /usr/libexec/gvfsd-admin --address unix:abstract=/tmp/dbus-J2bNTl2MbU
where unix:abstract=/tmp/dbus-.... is the DBUS session address, then I can open files / directories using the admin:// prefix.

I'm trying to figure out if there's a bug in gvfsd, or if there's a configuration option somewhere I need to change to enable the gvfsd-admin backend, or if my security settings are somehow blocking gvfsd from starting the gvfsd-admin backend.


Also, there's a typo in the man page. If copied and pasted directly from the man page. I believe the statement:

Code: Select all

...keeps track fo their lifecycle....
should actually read:

Code: Select all

...keeps track of their lifecycle...
(the word of has the letters reversed)

Thanks.
-- Niklaus Wirth's Law: software is getting slower more rapidly than hardware becomes faster.

Spork Schivago
Posts: 37
Joined: 2017/08/14 04:21:54

Re: gvfsd doesn't start gvfsd-admin when needed.

Post by Spork Schivago » 2018/02/09 21:49:24

Could someone please try to confirm if this is a bug in the gvfsd-admin backend or not?

A simple test would be to open a program like Nautilus, hit CTRL-L, and as a non-super user, type admin:///root to see if you're prompted for the root password or not.

If it times out on your machine as well, I think I need to file a bug report. I noticed in dmesg the following:

Code: Select all

[42094.083046] fuse init (API version 7.22)
[42098.844999] warning: `gvfsd-admin' uses 32-bit capabilities (legacy support in use)
I believe that message appears when I start gvfsd-admin manually for the first time. As a temporary work-around, I've created an auto-start file for X-Windows that executes a bash script that executes pkexec /usr/libexec/gvfsd-admin --address $DBUS_SESSION_BUS_ADDRESS, which allows me to use the gvfsd-admin backend.

Thanks!
-- Niklaus Wirth's Law: software is getting slower more rapidly than hardware becomes faster.

Spork Schivago
Posts: 37
Joined: 2017/08/14 04:21:54

Re: gvfsd doesn't start gvfsd-admin when needed.

Post by Spork Schivago » 2018/02/15 13:13:20

Guess I stumbled upon a bug in gvfs.

Here's a link to the bug and the fix:

https://bugzilla.gnome.org/show_bug.cgi?id=793445

This was the cause:

Code: Select all

Commit 8e9439ef introduced DBusName=org.gtk.vfs.mountpoint_admin
in admin.mount.in, but forgot to set the necessary mount options.
So, each client spawns new daemon currently, which is not necessary.
Let's set the missing -DMOUNTABLE_DBUS_NAME options.
I think it'll probably take some time for the pushed commit to work its way down to CentOS 7, wouldn't it? The very nice Ondrej Holy tested the bug on RedHat for me and I guess it's present there as well.

More than gvsd-admin is affected by this, but you don't realize it unless you try "debugging" gvfs by following what they suggest on their website.

When running gvfsd with the debug flag set, even opening just gedit displays the message Refusing to render to dead parents.

Anyway, now we know what's happening.

I wonder if there's a safe way to download the patch and install it somehow. I'd probably have to download the source to the RPM for gvfs, then manually check the diff file, to make sure it's patching the right stuff, modify if necessary, patch it, then just rebuild the RPM and install it like I'd normally would, right?

Can anyone see any faults with this, minus if there's an update that doesn't include the fix, my patched version will get overwritten...any thoughts?

Thanks!
-- Niklaus Wirth's Law: software is getting slower more rapidly than hardware becomes faster.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: gvfsd doesn't start gvfsd-admin when needed.

Post by TrevorH » 2018/02/15 13:38:03

I believe gnome3 is set for yet another rebase in 7.5, from 3.22 to 3.26.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Spork Schivago
Posts: 37
Joined: 2017/08/14 04:21:54

Re: gvfsd doesn't start gvfsd-admin when needed.

Post by Spork Schivago » 2018/03/26 02:39:44

TrevorH wrote:I believe gnome3 is set for yet another rebase in 7.5, from 3.22 to 3.26.
Would that include the gvfsd-admin fix that was pushed upstream? The bug that I found? Or don't you think it'd make it into that release?

Wonder when 7.5 is supposed to be coming.

I love CentOS 7, especially on my actual server. There's people on another forum trying to get me to switch to Microsoft Server! Yuck!

Wish I could understand KVM a bit more and fine tune it for my server, to have it run optimally. But I guess the CentOS forums isn't where questions like that should be asked.

Thanks for the help!
-- Niklaus Wirth's Law: software is getting slower more rapidly than hardware becomes faster.

Post Reply