GNOME Bugzilla – Bug 523911
gvfsd does not notice when backends are removed or added
Last modified: 2009-03-09 14:28:02 UTC
A running gvfsd process does not check that a backend still exists and when gvfs is started without a suitable backend, the gvfsd process created breaks. Installing the backend does not fix the problem because the existing (broken) process must be killed before the backend becomes usable. I came across this problem whilst trying to port a Debian-native application from GnomeVFS to GVfs and GIO. The problem then was that, with gvfs installed but without gvfs-backends, gvfs started, failed and left a broken process running. Installing the backends then didn't kill that broken process. Running the test code under sudo *after the backends were installed* allowed gvfs to work because that spawned a new gvfsd process for root. My original gvfsd process remained broken until I killed it. To reproduce (using Debian packages): Remove and purge only gvfs-backends - everything continues working. Kill the gvfs processes (to simulate a logout/login) and only then do things break. Install gvfs-backends again and things remain broken: $ sudo apt-get remove --purge gvfs-backends $ ps waux | grep gvfs (kill all gvfs processes - akin to rebooting after purging gvfs or getting close to a system that has never seen gvfs before.) $ gvfs-info http://www.google.com Error getting info: The specified location is not supported $ sudo apt-get install gvfs-backends $ gvfs-info http://www.google.com Error getting info: The specified location is not supported Not all users the particular application that I'm porting to GVfs will want to view remote files but if users try to use it for a remote file, get an error, work out to install gvfs-backends and try again, they get the same error until the old gvfsd process is killed. If gvfs-backends is installed *before* any gvfs processes try to use a backend, everything appears fine. In this broken situation, I get: $ dpkg -l 'gvfs*' ii gvfs 0.2.1-1 userspace virtual filesystem - server ii gvfs-backends 0.2.1-1 userspace virtual filesystem - backends ii gvfs-bin 0.2.1-1 userspace virtual filesystem - binaries $ ps waux | grep gvfs neil 25098 0.0 0.2 45104 2188 ? S 20:53 0:00 /usr/lib/gvfs/gvfsd neil 25134 0.0 0.0 5636 752 pts/13 R+ 20:55 0:00 grep --color gvfs Note lack of : /usr/lib/gvfs/gvfsd-http --spawner :1.592 /org/gtk/gvfs/exec_spaw/0 Kill that gvfsd process and it works again. In testing, it is crucial that an attempt to use gvfs for remote access is made before the backends are installed. In my testing, any subsequent tests will then fail until the broken gvfsd process is killed and a new one allowed to start.
The packaging of gvfs-backends need to killall -HUP gvfsd post install to have it reload the list of backends.
But in theory it should use inotify/whatever for this, right? Neil, could there be any reason why inotify or fam/gamin failed? :)
Not as far as I am aware, other file notifications work fine on both the systems affected (one powerpc, one amd64). Sebastian, have you been able to reproduce this problem by killing gvfsd, uninstalling gvfs-backends and trying to use gvfs for remote access without it installed ?
Sebastian: inotify/whatever could be used for this, but there are some cases where that doesn't work, like an NFS /usr. It could also stat the config file for changes on each time we get a "mount type not installed" lookup miss. But, at the moment it does neither of these, so adding the HUP to the package will solve the issue.
I consider this a packaging issue. Sending HUP on backend install will fix it in all cases, whereas a file monitor will break in some cases. So, closing this.