Bug 824139 - ejected data DVD fails to fully clean up after itself, subsequently inserted DVD fails to mount
Summary: ejected data DVD fails to fully clean up after itself, subsequently inserted ...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: udisks2
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Zeuthen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-22 20:01 UTC by Jonathan Kamens
Modified: 2013-03-06 04:08 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-05-22 21:54:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jonathan Kamens 2012-05-22 20:01:39 UTC
I had a DVD in my drive, mounted automatically as /run/media/jik/[name]. I don't think there were any processes using the DVD.

I ran "eject", and the DVD exited from the drive.

I saw this in /var/log/messages:

May 22 15:51:20 jik2 udisksd[2758]: Cleaning up mount point /run/media/jik/[name] (device 11:0 is not mounted)
May 22 15:51:20 jik2 udisksd[2758]: Error cleaning up mount point /run/media/jik/[name]: Error removing directory: Device or resource busy
May 22 15:51:20 jik2 udisksd[2758]: Unmounted /dev/sr0 on behalf of uid 3009
May 22 15:51:27 jik2 kernel: [106279.960842] VFS: busy inodes on changed media or resized disk sr0
May 22 15:51:27 jik2 udisksd[2758]: Cleaning up mount point /run/media/jik/[name] (device 11:0 is not mounted)
May 22 15:51:27 jik2 udisksd[2758]: Error cleaning up mount point /run/media/jik/[name]: Error removing directory: Device or resource busy

I put another data DVD in the drive and closed the drawer. Nothing happened. The drive was not mounted.

I tried ejecting it by pressing the eject button on the drive. Nothing happened.

I ejected it with "eject /dev/sr0" and then tried inserting it again. Again, it was not mounted.

I was able to mount the DVD by hand with "sudo mount /dev/sr0 /mnt/cdrom".

This happened the last time I tried to swap DVDs in my drive, so I don't think it's a fluke.

I'm current with updates-testing.

Comment 1 David Zeuthen 2012-05-22 20:04:08 UTC
I've seen this but I'm not sure it's a udisks2 bug. Please try reproducing without udisks2 (by e.g. mounting it manually at e.g. /mnt/cdrom) and then running eject(1) without unmounting the device.

Comment 2 David Zeuthen 2012-05-22 20:18:00 UTC
Actually I just tried to reproduce this and failed - it works fine for me (I'm using Linux 3.3.4-5.fc17.x86_64).

When putting in the new disc, please capture the following information

 - the output of 'udisksctl monitor'
 - the output of 'gvfs-mount -oi' captured from the desktop session as the user (not root)
 - the output of 'udevadm monitor --udev --property' (as root)

as well as whatever lines are logged (e.g. 'tail -f /var/log/messages' or similar) and paste it here.

Also attach the output of 'udisksctl dump' as a text file.

Comment 3 Jonathan Kamens 2012-05-22 20:46:29 UTC
I am now unable to reproduce the issue on demand with or without udisks2.

I'm sure I've seen it before, and I suspect I'll see it again, but I don't know specifically what is causing it or how to reproduce it.

Comment 4 David Zeuthen 2012-05-22 21:54:02 UTC
(In reply to comment #3)
> I am now unable to reproduce the issue on demand with or without udisks2.
> 
> I'm sure I've seen it before, and I suspect I'll see it again, but I don't
> know specifically what is causing it or how to reproduce it.

Looking more closely at the issue, I think something inside the kernel [1] is holding the device open:

 May 22 15:51:27 jik2 kernel: [106279.960842] VFS: busy inodes on changed media or resized disk sr0

This means that when we try to handle the 'change' uevent in udev (on media change), cdrom_id fails because it cannot open /dev/sr0 with O_EXCL. This causes subsequent udev rules to conclude there is no medium and then we don't run blkid(8) at all. This then bubbles up the stack....

So, yeah, this looks like a bug in the kernel that is causing user space to be confused as described in the paragraph above... feel free to reopen and reassign to the kernel if you can reproduce.

[1] : or something in userspace ... but nothing opens with O_EXCL by default ... and we have nothing opening the device file by default.


Note You need to log in before you can comment on or make changes to this bug.