I don't use any GNOME UI stuff, and in particular no gvfs, which
I think must mean GNOME virtual filesystem stuff. But I have to have
it installed because I use some applications that depend on
libgnome2-0.

Since I don't actually want any gvfs features, it would be nice if
debconf could ask me whether I'd like to disable starting of the
associated processes:

  madduck   5845  0.0  0.0  41132  1088 ?        S    Jul18   0:00 /usr/lib/gvfs/gvfsd
  madduck  14402  0.0  0.0 138380  1596 ?        Sl   Jul21   0:01 /usr/lib/gvfs/gvfs-hal-volume-monitor

as a means to save resources.

Thank you,

Today I catch several gvfs* daemons idle around on my system. As I
never ever used gnome desktop and I never want, I want them not to
start.

Unfortunately they get started by dbus automatically when a gnome
application like gimp is started. And afterwards they are left idling
around and consume resources.

So please consider Madducks will and disable that crap or ask a user if
he want to have this crap. I do not want at all and I think, starting
the daemons without asking the user is insolently.

Regards

severity 544148 normal
kthxbye

Version: 1.6.4-3

Package: gvfs or gvfs-backends

Upon upgrading to squeeze, I got bitten by this bug: I am used to downloading my
photos using gphoto2 on the command line. This is a perfectly legitimate and in
my case optimal workflow. I won't change it: I own the computer, not the other
way around.

The automatic starting of gvfs-gphoto2-volume-monitor breaks my workflow: I need
to manually unmount the camera before I can do anything (the fact that I was
also bitten by bug #546398 makes it even worse).

So this is a real bug, not just a wishlist. I would even have made it important,
because wantonly breaking minority use cases is not the linux way.

Thankfully, there is a workaround, thanks to Michael Biebl for proposing it in
bug #544483:

 > As dbus follows the xdg spec, you might wanna try to copy the service file to
 > /usr/local/share/dbus-1/system-services/ and set
 > Exec=/bin/false

 > This is an ugly hack though, so beware.

This solves the problem for me, and should be useful to the other reporters.
Note that you can *not* put the dummy service file in
$HOME/.local/share/dbus-1/system-services/ to disable the process per-user, as
that is only searched *after* the system dirs.

To solve this bug, at the very least, the workaround should be documented in
README.Debian. A cleaner solution would be to allow disabling some of the gvfs
backends through a gconf key for example.

Cheers,
Baptiste

Le lundi 28 février 2011 à 12:59 +0100, Baptiste Carvello a écrit :

Please don’t pollute bug reports. #544148 is about not starting the gvfs
daemons at all. Your problem, as I understand it, is not that a volume
monitor process is started: it is just a volume monitor and doesn’t act
upon itself. The actual mounting is initiated by nautilus, and you can
disable it in nautilus preferences.

Changing a bug severity will not magically fix it. But anyway, there’s
no bug here since you can already disable auto-mounting.

Le 28/02/2011 14:17, Josselin Mouette a écrit :
Mounting volumes per se is not the problem. Breaking command line access
is. So I don't want to disable *all* volume mounting, just the broken
gphoto2 ones.
Not acknowledging bugs affecting non-desktop use cases won't fix them,
either.

Le lundi 28 février 2011 à 14:31 +0100, Baptiste Carvello a écrit :

Good. Since nautilus allows to specify a different action for each media
type.

In all cases this is a different bug from #544148. So don’t hijack bugs
and open new ones for different issues.

Because acknowledging a bug magically fixes it, as we all know.

Le 28/02/2011 14:49, Josselin Mouette a écrit :
did you test that? I was proposed several actions, but *all of them*
mounted the drive first, including the "do nothing" action. My current
nautilus configuration is :

~$ gconftool-2 -a /apps/nautilus/preferences|grep media
  media_autorun_x_content_start_app =
[x-content/audio-cdda,x-content/video-dvd,x-content/audio-dvd,x-content/video-bluray,x-content/blank-dvd,x-content/video-vcd,x-content/blank-cd,x-content/video-svcd]
  media_automount_open = false
  media_autorun_x_content_ignore =
[x-content/audio-player,x-content/software,x-content/image-picturecd,x-content/blank-bd,x-content/blank-hddvd,x-content/unix-software,x-content/win32-software,x-content/image-dcf]
  media_autorun_never = false
  media_automount = true
  media_autorun_x_content_open_folder = []
  media_autorun_x_content_ask = []

Setting media_autorun_never to true does not help.
Setting media_automount to false prevents nautilus from mounting *any*
volumes.
The inflexibility of the gvfs implementation prevents me from easily solving (or working around) my problem. So this *is* at least partly #544148. Also, the way I finally solved it might be of interest to the reporters of this bug. Feel free to also open a bug on nautilus if you wish. Also feel free to not answer if you think it "pollutes" or "hijacks".

Hello,

I have just hit this bug, when I was trying to:

$ sudo mount //winhost/share mydir
$ sudo umount mydir
umount: /home/javi/proyectos/dsp/NetApp/dominio/javi/oficina: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
$ lsof | grep mydir
gvfs-udis 3806    ...
gdbus     3806 3807 ,,,
gmain     3806 3808 ....
pool      3806 4029 ...

I'm using awesome as wm. How can I disable all gnome daemons to no
lookup at new mount points ?

I have tried without success:
$ sudo systemctl stop udisks2.service
$ sudo systemctl status udisks2.service
● udisks2.service - Disk Manager
   Loaded: loaded (/lib/systemd/system/udisks2.service; static)
   Active: active (running) since jue 2014-11-27 12:04:21 CET; 11s ago
     Docs: man:udisks(8)
 Main PID: 4069 (udisksd)
   CGroup: /system.slice/udisks2.service
           └─4069 /usr/lib/udisks2/udisksd --no-debug


sudo systemctl stop run-user-1000-gvfs.mount

After kill -9 gvfs-udisk proccess it started to work, is there any
command to force this service not get started ?

Thank you very much

Thank you