When pressing the CD drive eject button while the CD is mounted, udisks normally force-unmounts the CD to avoid stale mounts: **** CHANGING /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 **** UPDATING /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 **** NOTE: Force unmounting device /dev/sr0 **** EMITTING JOB-CHANGED for /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 helper(pid 18840): launched job umount on /dev/sr0 [...] helper(pid 18840): completed with exit code 0 **** NOTE: Successfully force unmounted device /dev/sr0 However, this does not work if the CD is in /etc/fstab, which is still a fairly common setup from older Linux distro installations: **** CHANGED /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 helper(pid 3113): completed with exit code 0 **** UPDATING /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0 **** Unlocking CD-ROM door for /dev/sr0 **** EMITTING JOB-CHANGED for /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0/block/sr0
The problem is in force_removal(): | if (device->priv->device_is_mounted && device->priv->device_mount_paths->len > 0) This condition is fine, udisks properly tracks mounts in fstab. | { | gboolean remove_dir_on_unmount; | | if (mount_file_has_device (device->priv->device_file, NULL, &remove_dir_on_unmount)) This is the culprit. The mount won't be in /var/lib/udisks/mtab, thus force_unmount() is never called. | { | g_print ("**** NOTE: Force unmounting device %s\n", |device->priv->device_file); | force_unmount (device, callback, user_data); So there are two options: - Don't care about mount_file_has_device() and always clean up stale mounts. This is certainly a valid approach, and I don't see the value of keeping around stale mounts, but there might be cases, or simply a definition, that udisks shouldn't interfere with mounts at all that it didn't mount in the first place. - Add alternative check if fstab has the device. I'd go with the second approach for now.
Created attachment 34038 [details] [review] check for fstab drives in force_unmount With this patch, udisks properly cleans up stale mounts for CD-ROMs if they are in /etc/fstab. David, does that look okay to you?
(In reply to comment #2) > Created an attachment (id=34038) [details] > check for fstab drives in force_unmount > > With this patch, udisks properly cleans up stale mounts for CD-ROMs if they are > in /etc/fstab. > > David, does that look okay to you? > Actually, I don't think this is correct (specifically: we only want to force-unmount the device if it was actually mounted by udisks itself)... but it's probably good enough for now. For the record, bug 24279 is the bug for tracking the more general problem.
Also this is actually a dupe of bug 24708 (please read it including the link to the gnome bug) but I'm closing the other one since there is more information here.
*** Bug 24708 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Actually, I don't think this is correct (specifically: we only want to > force-unmount the device if it was actually mounted by udisks itself) Hm, we could write a record into /var/lib/udisks/mtab if udisks mounted something in fstab? That might indeed be a better fix, since right now we don't know whether it was the user or udisks once udisks-daemon is done with the mount.
(In reply to comment #3) >... but it's probably good enough for now. I pushed the fix to git, but I'll keep this bug open for discussing how to fix it in a better way (like tracking fstab mounts by udisks in /var/lib/udisks/mtab?)
With udisks 2.0 this is no longer a problem I think. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.