gvfsd-trash probes devices not in /run/media, keeping the device busy

[David James]

Right now, if you mount a loop device on Ubuntu Precise, gvfs-gdu-volume-monitor grabs hold of the mount, preventing it from being unmounted. I've attached a script (gvfs-test.sh) which reproduces the problem reliably on Ubuntu Precise.

Ubuntu has a setting which should disable this automount behavior, but it doesn't work: I tried setting System Settings -> Details -> Removable Media -> Never prompt or start programs on media insertion, but gvfs-gdu-volume-monitor still grabs hold of loop devices. This bug is present in Ubuntu Precise but is not present in Ubuntu Lucid.

With the attached script (gvfs-test.sh), it fails with the following message:

+ sudo bash -c 'mount /dev/loop0 /tmp/tmp.A8gsvsAc7T-gvfs-test && umount /tmp/tmp.A8gsvsAc7T-gvfs-test'
umount: /tmp/tmp.A8gsvsAc7T-gvfs-test: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Killing gvfs-gdu-volume-monitor works around the problem. You can also work around the bug by sleeping for a few seconds prior to unmounting the loop device.

There are two related bugs here:
  1) gvfs-gdu-volume-monitor should not be touching loop devices at all -- they are not removable media so they should not be automounted.
  2) It should be possible to disable the automount behavior of gvfs-gdu-volume-monitor.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Sebastien Bacher (seb128)]

(I will have a look tomorrow but it would still be nice to upstream the issue because it's not likely Ubuntu specific)

[David James (davidjames)]

Thanks for the quick response. I've reported this bug upstream to Gnome as well: https://bugzilla.gnome.org/show_bug.cgi?id=677648

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David James (davidjames)]

Adding the following rules to /etc/udev/rules.d/86-no-automount.rules fixes the problem locally:

ENV{UDISKS_PRESENTATION_HIDE}="1"
KERNEL=="sd*|hd*|sr*|mmcblk*|mspblk*", ENV{UDISKS_PRESENTATION_HIDE}="0"

Any chance we can add these rules into the default configuration? There seems to be no reason for Ubuntu to automount loop devices...

[David James (davidjames)]

Tested some more locally and the above fix solves half the problem. The other half of the problem is that the gvfs trash daemon creates a .Trash directory inside mount points.

This problem can be worked around entirely using the following workaround:
  sudo killall -STOP gvfs-gdu-volume-monitor gvfsd-trash

We use the above workaround in the Chrome OS build system to ensure that gvfs doesn't mess with our loop devices. There must be a better way...

[David James (davidjames)]

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

This is the test script on F16 (from a F16 live CD)... it works as expected.
See https://bugzilla.gnome.org/attachment.cgi?id=216431

Looks like your problem is specific to Ubuntu then... can you or an Ubuntu
developer please check what vendor patches are used?

(Just a note: F16 is using the same old gvfs-gdu-volume-monitor process as you
are on Ubuntu. It's F17 that is using the new udisks2-based stuff.)

Sebastien, any chance you could check what vendor patches are being used and whether this bug is triggered by a Ubuntu-specific patch?

[Sebastien Bacher (seb128)]

@David: I've just read the upstream discussion, great to see the details and progresses there. Martin Pitt who is the Ubuntu maintainer stack told me he would have a look at this bug today but I guess that didn't make it on his todo list for the day but I will make sure we look at it tomorrow (our number of patches on that stack is limited though (i.e we have only non linux and build system changes to gvfs)

[Martin Pitt (pitti)]

I started trying this on current quantal, which uses the latest gvfs and udisks2. I can reproduce the "device is busy" race condition with the attached script sometimes (that race condition is rather hard to catch on my system). However, I never get the loop device to automount, the problem is apparently that gvfs notices the manual mount and then does its .Trash thing there.

When I exercise the steps manually, I see in "gvfs-mount -oi" that after

   sudo losetup /dev/loop0 /tmp/img

gvfs sees the new volume:

Volume added: 'Datenträger 10 MB'
  Volume(0): Datenträger 10 MB
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/loop0'
     uuid: '6a3142af-c40d-455c-b4a3-5a7ae9456d41'
    themed icons: [drive-removable-media]
    can_mount=1
    can_eject=0
    should_automount=0
    sort_key=gvfs.time_detected_usec.1339748763777673

should_automount is correctly at "0", i. e. it does not automount it. Once I manually mount it, it goes away:

    sudo mount /dev/loop0 /tmp/gvfstest

Volume removed: 'Datenträger 10 MB'
  Volume(0): Datenträger 10 MB
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/loop0'
     uuid: '6a3142af-c40d-455c-b4a3-5a7ae9456d41'
    themed icons: [drive-removable-media]
    can_mount=1
    can_eject=0
    should_automount=0
    sort_key=gvfs.time_detected_usec.1339748763777673

That might look confusing at first, but only shows that gvfs is correctly ignoring mounts that are not in /media/ (or /run/media/ for udisks2 these days).

Can you please confirm that gvfs does not actually automount the loop device? I. e. if you run the losetup/losetup -d in a loop, gvfs never automounts it? "gvfs-mount -oi" should never show "should_automount=1". If you confirm this, then we are actually seeing the same issue.

I never get the "busy" problem if I only SIGSTOP gvfsd-trash. I suspect what happens is that gvfsd-trash is watching for new mounts (I can see it accessing /proc/mounts in strace), accesses new mounts to do its thing, and that races with the very quick unmount; if I put a "sleep 0.1" in between mount and unmount, I never get the "busy" either.

Can you confirm this?

[Sebastien Bacher (seb128)]

@David: could you reply to Martin's comment and confirm that gvfs doesn't automount the device?