Bug 909418

so does it still appear in /proc/mounts after the eject?

Normally the kernel should lock the drive's eject function while mounted.

Yes, the mount still appears in /proc/mounts after the tray is open:
/dev/sr0 /run/media/windl/LO\040NA-DVD\0404.0.5 udf ro,nosuid,nodev,relatime,uid=1000,gid=100,umask=77,iocharset=utf8 0 0

In Syslog I see this message:
Dez 11 19:34:21 i7a kernel: VFS: busy inodes on changed media or resized disk sr0

Some info about the drive (this drive had no such problem in openSUSE 12.3, so I guess it's not the drive hardware):
  Hardware Class: cdrom
  Model: "HL-DT-ST BD-RE  BH10LS30"
  Vendor: "HL-DT-ST"
  Device: "BD-RE  BH10LS30"
  Revision: "1.01"
  Driver: "ahci", "sr"
  Driver Modules: "ahci"
  Device File: /dev/sr0 (/dev/sg2)
  Device Files: /dev/sr0, /dev/cdrom, /dev/cdrw, /dev/disk/by-id/ata-HL-DT-ST_BD-RE_BH10LS30_K9JB37M1913, /dev/disk/by-path/pci-0000:00:1f.2-ata-3.0, /dev/dvd, /dev/dvdrw
  Device Number: block 11:0 (char 21:2)
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL, BD, BD-R, BD-RE, DVD-RAM
  Drive status: no medium
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #14 (RAID bus controller)
  Drive Speed: 125

I set up the system so that only admin may mount or umount filesystems (when
mounting I'm asked for the root password). Just in case this matters...

I also noticed that double clicking on the DVD in the file browser (left frame), nothing happens; I have to use right mouse button and select "open" to cause mount of medium (the a prompt for root password pops up).

Before the first mount I found the following syslog messages (but possibly the drive was not ready then):
Dez 11 19:33:33 i7a kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dez 11 19:33:33 i7a kernel: sr 2:0:0:0: CDB: 
Dez 11 19:33:33 i7a kernel: Xdread, Read track info: 52 01 00 00 00 02 00 00 08 00
Dez 11 19:33:33 i7a kernel: ata3.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 25 pio 16392 in
                                         res 40/00:03:00:fc:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Dez 11 19:33:33 i7a kernel: ata3.00: status: { DRDY }
Dez 11 19:33:33 i7a kernel: ata3: hard resetting link
Dez 11 19:33:33 i7a kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Dez 11 19:33:33 i7a kernel: ata3.00: configured for UDMA/133
Dez 11 19:33:33 i7a kernel: ata3: EH complete
Dez 11 19:33:33 i7a kernel: sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 02 00 00 08 00
Dez 11 19:33:33 i7a kernel: sr: Sense Key : Aborted Command [current] [descriptor]
Dez 11 19:33:33 i7a kernel: sr: Add. Sense: No additional sense information
Dez 11 19:33:35 i7a kernel: UDF-fs: INFO Mounting volume 'LO NA-DVD 4.0.5', timestamp 2013/09/13 21:39 (103c)
Dez 11 19:33:35 i7a udisksd[1849]: Mounted /dev/sr0 at /run/media/windl/LO NA-DVD 4.0.5 on behalf of uid 1000
Dez 11 19:33:35 i7a org.gtk.Private.UDisks2VolumeMonitor[2213]: libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /run/media/windl/LO NA-DVD 4.0.5/BDMV/index.bdmv
Dez 11 19:33:35 i7a org.gtk.Private.UDisks2VolumeMonitor[2213]: libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /run/media/windl/LO NA-DVD 4.0.5/BDMV/BACKUP/index.bdmv
Dez 11 19:33:38 i7a org.gnome.Nautilus[2213]: (nautilus:2624): Gtk-CRITICAL **: gtk_revealer_set_reveal_child: assertion 'GTK_IS_REVEALER (revealer)' failed
Dez 11 19:33:41 i7a org.gnome.Nautilus[2213]: openjdk version "1.8.0_40"
Dez 11 19:33:41 i7a org.gnome.Nautilus[2213]: OpenJDK Runtime Environment (build 1.8.0_40-b10)
Dez 11 19:33:41 i7a org.gnome.Nautilus[2213]: OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode)

If I mount the DVD manually (mount -r /dev/sr0 /mnt), /proc/mount has:
/dev/sr0 /mnt udf ro,relatime,utf8 0 0
Still a short press of the eject button ejects the media, and the mount entry is still in /proc/mounts.
The only related syslog messages then are:
Dez 11 19:49:36 i7a kernel: UDF-fs: INFO Mounting volume 'LO NA-DVD 4.0.5', timestamp 2013/09/13 21:39 (103c)
Dez 11 19:50:33 i7a kernel: VFS: busy inodes on changed media or resized disk sr0

(The DVD is some older LibreOffice DVD "ISO" image (LibreOffice 4.0.5 DVD))
SATA controller is a recent Intel ICH on an Asus Z87-C board.
I suspect this might be a kernel problem.

Maybe this helps: I found out that the "GNOME live CD" has the very same problem on a completely different hardware (a HP DL320e G8 v2 server): You can eject the CD while the live system is running from CD.

I checked a test machine and indeed a DVD can be ejected while mounted.
But this behavior is seen no matter which kernel is: at least, I could reproduced with openSUSE 12.3 3.7.x kernel, too.  So, it's no recent regression, if any.

Didn't you see this behavior earlier?

(In reply to Takashi Iwai from comment #4)
Good question! If the problem still existed in 12.3 (i586), I did not realize it, at least. I skipped 13.1, so I cannot tell, and for 13.2 I'm sure.
I think if things work correctly, the kernel should SCSI-lock the drive's try once a filesystem is mounted, and on unmount the lock should be released. It seems this does not happen.

This turned out to be no kernel regression.  SLE11-SP3 behaves as expected (the try locked while mounted) even with openSUSE 13.2 kernel running on it.

Now Oliver found out that the problem comes from a udev rule, /usr/lib/udev/rules.d/60-cdrom_id.rules.  The line forcibly ejects per the eject button:

# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

Removing this would prevent the forced eject, but the eject button won't work because the try is locked by the line:

IMPORT{program}="cdrom_id --lock-media $devnode"

You need to remove --lock-media option in this line, too.  After these changes, the system should work like SLE11.

I reassign this to systemd guys, as it's a clear regression of udev.
(BTW, the behavior was seen on openSUSE 13.1, too, so no new bug for 13.2).

Takashi, this cant be udev issue, the implemention of lock-media and eject-media has been in udev since 2011:

commit b20fd3cb3423676a86f12189126b012d2297d5f7
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Sat Jun 18 20:54:47 2011 +0200

    cdrom_id: add tray lock and eject handling

Or at least is not exactly the issue with locking and ejecting.

(In reply to Robert Milasan from comment #7)
> Takashi, this cant be udev issue,

It is.  We confirmed that just changing udev rules fixes the problem.

> the implemention of lock-media and
> eject-media has been in udev since 2011:
> 
> commit b20fd3cb3423676a86f12189126b012d2297d5f7
> Author: Kay Sievers <kay.sievers@vrfy.org>
> Date:   Sat Jun 18 20:54:47 2011 +0200
> 
>     cdrom_id: add tray lock and eject handling
> 
> Or at least is not exactly the issue with locking and ejecting.

So it has been "broken" since then :)  It's no new regression after all.

I'm testing this in openSUSE 13.2 in a VirtualBox and forceing VBox to change the ISO (the CD/DVD in other words) and works perfectly.

Can you try to monitor add/change events in one console or terminal?

Something like:

udevadm monitor -k -p

and attach the output to the bug?

I would like to see whats going on.

OK, this is about 90% a kernel issue. I've done some more test and looks like there are no change events when the hardware button (eject) is pressed.

So when we eject the cd media and we put a new disk in it, it suppose to have 2 events, one for the eject itself and one for the media change, we only have the second one. This actually works in 13.1, but not in 13.2.

Please recheck Takashi.

BTW, even like that for me it works in 13.2, which version of kernel are you using Ulrich?

(In reply to Robert Milasan from comment #10)
> OK, this is about 90% a kernel issue. I've done some more test and looks
> like there are no change events when the hardware button (eject) is pressed.
> 
> So when we eject the cd media and we put a new disk in it, it suppose to
> have 2 events, one for the eject itself and one for the media change, we
> only have the second one. This actually works in 13.1, but not in 13.2.
> 
> Please recheck Takashi.

linux-0dmf:/usr/lib/udev/rules.d # udevadm monitor -k -p
monitor will print the received events for:
KERNEL - the kernel uevent

KERNEL[83652.573173] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
ACTION=change
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=11
MINOR=0
SEQNUM=2864
SUBSYSTEM=block

KERNEL[83667.933326] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
ACTION=change
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
DISK_EJECT_REQUEST=1
MAJOR=11
MINOR=0
SEQNUM=2865
SUBSYSTEM=block

KERNEL[83672.484749] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
ACTION=change
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=11
MINOR=0
SEQNUM=2866
SUBSYSTEM=block

(In reply to Robert Milasan from comment #10)
> OK, this is about 90% a kernel issue. I've done some more test and looks
> like there are no change events when the hardware button (eject) is pressed.
>

I suggest you forget about VirtualBox. Get real hardware.

So it actually work as it suppose to. I cant reporduce this in 13.1 nor 13.2 using Gnome and/or Cinnamon.

OK, for 13.2 I'll get a new hardware for it, but definitely 13.1 works.


Will try to get back to you tomorrow.

(In reply to Robert Milasan from comment #14)
> So it actually work as it suppose to. I cant reporduce this in 13.1 nor 13.2
> using Gnome and/or Cinnamon.

I just retested 13.1 and 13.2 you can eject a mounted DVD.
Both distros show both events.

To me this udev rule looks like unnecessary stuff that really only makes matters worse. Leaving this to the kernel works without a problem.

(In reply to Robert Milasan from comment #14)
> So it actually work as it suppose to.

No, udev rule is doing wrong.  It should have some sanity check or doing umount at least like eject command does.

> I cant reporduce this in 13.1 nor 13.2
> using Gnome and/or Cinnamon.

Better to avoid GNOME.  It might be that GNOME does something special.
Just go to Linux console, and mount manually, and press eject event.

And watch out udevadm monitor whether you get EJECT event, as Oliver put in comment 12.  If no EJECT is seen, your hardware is an exception.

OK, will do, thanks.

I guess, the fix can be done on Monday too. BTW, we will need cdrom binary to run at least once in the rule. So, I'll check to see how it would be the best idea.

(In reply to Robert Milasan from comment #17)
> OK, will do, thanks.
> 
> I guess, the fix can be done on Monday too. BTW, we will need cdrom binary
> to run at least once in the rule. So, I'll check to see how it would be the
> best idea.

Thanks.  Easy workarounds that came to my mind are:
1. remove --lock-media option and eject entry.
2. replace "cdrom_id --eject" call with "/usr/bin/eject".
3. hack cdrom_id to check mount before performing eject.

1 is to revert to the old state.  It's confirmed to work, but we need to know why the explicit lock and eject calls were added in the past above all.

2 is easy, does umount, but this of course doesn't block the eject like before.  Maybe this is no go.

For 3, I quickly tested the onliner patch below.  However, this seems confusing KDE, at least.  When the eject button is pressed, KDE removes the DVD icon on Dolphin window even if it's still there (thus you can't unmount from GUI any longer).  Maybe someone is listening to the eject event as well?  It's puzzling why this problem isn't seen with the option 1, though...

--- a/src/udev/cdrom_id/cdrom_id.c
+++ b/src/udev/cdrom_id/cdrom_id.c
@@ -983,7 +983,7 @@ work:
                 media_lock(udev, fd, false);
         }
 
-        if (eject) {
+        if (eject && !is_mounted(node)) {
                 log_debug("PREVENT_ALLOW_MEDIUM_REMOVAL (unlock)");
                 media_lock(udev, fd, false);
                 log_debug("START_STOP_UNIT (eject)");

(In reply to Robert Milasan from comment #9)
> udevadm monitor -k -p

My kernel is 3.16.7-7-desktop (x86_64). I started the command above when the DVD was mounted. Then I pressed eject botton on the drive, and the tray opened after a moment. After that mount still shows
/dev/sr0 on /run/media/windl/openSUSE-13.2-DVD-x86_640051 type iso9660 ...

It seems udev just receives two events:
DISK_EJECT_REQUEST=1
DISK_MEDIA_CHANGE=1

Created attachment 619195 [details]
Output of "udevadm monitor -k -p"

(In reply to Ulrich Windl from comment #19)
> (In reply to Robert Milasan from comment #9)
> > udevadm monitor -k -p
> 
> My kernel is 3.16.7-7-desktop (x86_64). I started the command above when the
> DVD was mounted. Then I pressed eject botton on the drive, and the tray
> opened after a moment. After that mount still shows
> /dev/sr0 on /run/media/windl/openSUSE-13.2-DVD-x86_640051 type iso9660 ...
> 
> It seems udev just receives two events:
> DISK_EJECT_REQUEST=1
> DISK_MEDIA_CHANGE=1

Could you check that modifying udev rules fixes the issue as in comment 6?

Takashi, are you saying that this is the fix?

--- 60-cdrom_id.rules.orig	2015-01-12 09:43:47.919780913 +0100
+++ 60-cdrom_id.rules	2015-01-12 09:44:06.644876676 +0100
@@ -9,11 +9,11 @@
 KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"
 
 # media eject button pressed
-ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"
+ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id $devnode", GOTO="cdrom_end"
 
 # import device and media properties and lock tray to
 # enable the receiving of media eject button events
-IMPORT{program}="cdrom_id --lock-media $devnode"
+IMPORT{program}="cdrom_id $devnode"
 
 KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"
 KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", OPTIONS+="link_priority=-100"

Or this? 

--- 60-cdrom_id.rules.orig	2015-01-12 09:43:47.919780913 +0100
+++ 60-cdrom_id.rules	2015-01-12 09:48:55.364352280 +0100
@@ -8,12 +8,9 @@
 # unconditionally tag device as CDROM
 KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"
 
-# media eject button pressed
-ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"
-
 # import device and media properties and lock tray to
 # enable the receiving of media eject button events
-IMPORT{program}="cdrom_id --lock-media $devnode"
+IMPORT{program}="cdrom_id $devnode"
 
 KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"
 KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", OPTIONS+="link_priority=-100"

The latter one worked as far as I tested.

If I remove the "--lock-media" option I get a strange result. The button works again on unmounted media. But there's no event. With a mounted medium the button doesn't eject the CD, yet an event is generated. It seems like this interface is flawed, if you want consistent notification about events for a GUI.


linux-0dmf:/usr/lib/udev/rules.d # udevadm monitor -k -p
monitor will print the received events for:
KERNEL - the kernel uevent

KERNEL[34242.269050] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
ACTION=change
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=11
MINOR=0
SEQNUM=4252
SUBSYSTEM=block

KERNEL[34272.733186] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
ACTION=change
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=11
MINOR=0
SEQNUM=4253
SUBSYSTEM=block

^Clinux-0dmf:/usr/lib/udev/rules.d # mount /dev/sr0 /mnt
mount: /dev/sr0 is write-protected, mounting read-only
linux-0dmf:/usr/lib/udev/rules.d # udevadm monitor -k -p
monitor will print the received events for:
KERNEL - the kernel uevent
                                                                                                                                                                                                                                  
KERNEL[34312.669165] change   /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 (block)                                                                                                                   
ACTION=change                                                                                                                                                                                                                    DEVNAME=/dev/sr0                                                                                                                                                                                                                  
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0                                                                                                                                                 
DEVTYPE=disk                                                                                                                                                                                                                      
DISK_EJECT_REQUEST=1                                                                                                                                                                                                              
MAJOR=11                                                                                                                                                                                                                          
MINOR=0                                                                                                                                                                                                                           
SEQNUM=4255                                                                                                                                                                                                                       
SUBSYSTEM=block

I tested both, they don't work.

Here is the scenario:

1. insert CD/DVD in the drive
2. mount the drive: mount /dev/sr0 /mnt (just an example)
3. eject CD/DVD from the drive
4. insert a new CD/DVD in the drive
5. ls /mnt (will be empty or junk, plus a lot of errors in dmesg)

(In reply to Robert Milasan from comment #26)
> I tested both, they don't work.
> 
> Here is the scenario:
> 
> 1. insert CD/DVD in the drive
> 2. mount the drive: mount /dev/sr0 /mnt (just an example)
> 3. eject CD/DVD from the drive

Who eject the media?  Does the hardware do it by itself, or does the system issue any SCSI command (apparently but for udev)?

I pressed the hardware button, I didn't pay attention.

(In reply to Oliver Neukum from comment #25)
> If I remove the "--lock-media" option I get a strange result. The button
> works again on unmounted media. But there's no event. With a mounted medium
> the button doesn't eject the CD, yet an event is generated. It seems like
> this interface is flawed, if you want consistent notification about events
> for a GUI.

I confirmed this behavior, too.  And it actually leaves the DVD icon even after the media is ejected.  So this is no perfect solution, either.  Hmm.

FYI, I'm building a kernel with a test workaround patch in OBS home:tiwai:bnc909418 repo.  Please check it later whether this works around the problem without udev rules modification.

(In reply to Takashi Iwai from comment #30)
> FYI, I'm building a kernel with a test workaround patch in OBS
> home:tiwai:bnc909418 repo.  Please check it later whether this works around
> the problem without udev rules modification.

I am afraid it does not have the desired effect under GNOME. The events are filtered. However it looks like GNOME always mounts. The eject button never works with the patched kernel.

(In reply to Oliver Neukum from comment #31)
> (In reply to Takashi Iwai from comment #30)
> > FYI, I'm building a kernel with a test workaround patch in OBS
> > home:tiwai:bnc909418 repo.  Please check it later whether this works around
> > the problem without udev rules modification.
> 
> I am afraid it does not have the desired effect under GNOME. The events are
> filtered. However it looks like GNOME always mounts. The eject button never
> works with the patched kernel.

You can eject by the right pulldown menu on the DVD icon.

And on SLES, the root password is asked to mount.  When you cancel at this point, no mount is done, and the eject button works.

I checked the behavior on SP3, and it's same.  It mounts and opens the file browser as default per insert, and the eject button doesn't work.

(In reply to Takashi Iwai from comment #32)

> You can eject by the right pulldown menu on the DVD icon.
> 
> And on SLES, the root password is asked to mount.  When you cancel at this
> point, no mount is done, and the eject button works.
> 
> I checked the behavior on SP3, and it's same.  It mounts and opens the file
> browser as default per insert, and the eject button doesn't work.

I can confirm that the patched kernel works under this circumstances. But is that useful? And I don't see how we can get this upstream.

(In reply to Oliver Neukum from comment #33)
> (In reply to Takashi Iwai from comment #32)
> 
> > You can eject by the right pulldown menu on the DVD icon.
> > 
> > And on SLES, the root password is asked to mount.  When you cancel at this
> > point, no mount is done, and the eject button works.
> > 
> > I checked the behavior on SP3, and it's same.  It mounts and opens the file
> > browser as default per insert, and the eject button doesn't work.
> 
> I can confirm that the patched kernel works under this circumstances. But is
> that useful? And I don't see how we can get this upstream.

We can try upstreaming the patch (but maybe flipping the flag off as default at first to keep the compatible behavior).  It's not only us who suffers from this problem.

Currently *everyone* abuses the DISK_EJECT_REQUESTED event, expecting that the device is ready to eject, not "requested" to eject.  Fixing all these usages is one way, but adapting these expectation would be more practical in this case.

(In reply to Takashi Iwai from comment #34)
>
> We can try upstreaming the patch (but maybe flipping the flag off as default
> at first to keep the compatible behavior).  It's not only us who suffers
> from this problem.
> 
> Currently *everyone* abuses the DISK_EJECT_REQUESTED event, expecting that
> the device is ready to eject, not "requested" to eject.  Fixing all these
> usages is one way, but adapting these expectation would be more practical in
> this case.

True , but that would call for a third event type, not just switching it off. We cannot just drop information.

(In reply to Oliver Neukum from comment #35)
> (In reply to Takashi Iwai from comment #34)
> >
> > We can try upstreaming the patch (but maybe flipping the flag off as default
> > at first to keep the compatible behavior).  It's not only us who suffers
> > from this problem.
> > 
> > Currently *everyone* abuses the DISK_EJECT_REQUESTED event, expecting that
> > the device is ready to eject, not "requested" to eject.  Fixing all these
> > usages is one way, but adapting these expectation would be more practical in
> > this case.
> 
> True , but that would call for a third event type, not just switching it
> off. We cannot just drop information.

We drop it conditionally and it's under control.  If anyone needs to avoid filtering, it can be disabled even dynamically.

I doubt whether we'd need a third event type for the time being.  If it's really needed, someone has to point out the real code that uses it at first.

(In reply to Takashi Iwai from comment #21)
> Could you check that modifying udev rules fixes the issue as in comment 6?

I found that my system has no rule starting with "60-cdrom_id.rules"; I only see these rules: 55-libsane.rules  56-sane-backends-autoconfig.rules  70-persistent-net.rules
Ah, I see: There are more rules in /usr/lib/udev/rules.d!
So I just commented the first line (--eject-media), and my tray won't open, even if the DVD is not mounted!
When also commenting the second line (--lock-media) (and ejecting/reloading the media using the "eject" command, the tray would open when the media was not mounted, but the tray would also open when the media was mounted (kernel: VFS: busy inodes on changed media or resized disk sr0)!
I re-tried after "udevadm control -R": When not mounted, the tray will open, and the tray will also open when the media was mounted.
As I said in comment 0: "I suspect this might be a kernel problem."

(In reply to Ulrich Windl from comment #37)
> (In reply to Takashi Iwai from comment #21)
> > Could you check that modifying udev rules fixes the issue as in comment 6?
> 
> I found that my system has no rule starting with "60-cdrom_id.rules"; I only
> see these rules: 55-libsane.rules  56-sane-backends-autoconfig.rules 
> 70-persistent-net.rules
> Ah, I see: There are more rules in /usr/lib/udev/rules.d!
> So I just commented the first line (--eject-media), and my tray won't open,
> even if the DVD is not mounted!
> When also commenting the second line (--lock-media) (and ejecting/reloading
> the media using the "eject" command, the tray would open when the media was
> not mounted, but the tray would also open when the media was mounted
> (kernel: VFS: busy inodes on changed media or resized disk sr0)!

eject command may do this.

> I re-tried after "udevadm control -R": When not mounted, the tray will open,
> and the tray will also open when the media was mounted.
> As I said in comment 0: "I suspect this might be a kernel problem."

Please read through the whole bugzilla comments (this and bug 912715).

I still didn't get the test result of comment 30.  Please test the kernel package there *without* modification of udev rules.

Just for clarification:
In test for this bug, you must press the physical button. That cannot be substituted by software.

Is this now a kernel or a udev/systemd issue?

Closing as it should be fixed by the next update.

This is an autogenerated message for OBS integration:
This bug (909418) was mentioned in
https://build.opensuse.org/request/show/447363 13.1 / systemd
https://build.opensuse.org/request/show/447364 13.2 / systemd

SUSE-RU-2017:0013-1: An update that has 11 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1012390,1012591,1012818,1013989,1015515,909418,912715,945340,953807,963290,990538
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    systemd-228-126.1
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    systemd-228-126.1
SUSE Linux Enterprise Server 12-SP2 (src):    systemd-228-126.1
SUSE Linux Enterprise Desktop 12-SP2 (src):    systemd-228-126.1

The implemented patch seems to cause an assertion fault, in particular I can observe:

systemd[11505]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting.
systemd[1]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting.
systemd[1]: Caught <ABRT>, dumped core as pid 30128.
systemd[1]: Freezing execution.

It looks like it is valid for dev to be NULL in device_setup_unit(Manager *m, struct udev_device *dev, const char *path, bool main). At least there are various guards with if (dev) in the source.

This is not checked before the (new) call to device_is_bound_by_mounts(), which itself does assert(dev). As a result, PID1 aborts and the system cannot be managed any more. I'm not familiar with the new logic, but the fix may be a simple guard condition inside device_is_bound_by_mounts().

Note that this would halt a production machine hard, being unable to even reboot normally (since the system dbus is down

Upstream Issue: https://github.com/systemd/systemd/issues/5025

Please open a new bug report.

This is an autogenerated message for OBS integration:
This bug (909418) was mentioned in
https://build.opensuse.org/request/show/449511 13.1 / systemd
https://build.opensuse.org/request/show/449514 13.2 / systemd

openSUSE-RU-2017:0180-1: An update that has 6 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1012591,1013989,1018399,909418,912715,945340
CVE References: 
Sources used:
openSUSE 13.2 (src):    systemd-210.1484047020.83cb8e58d-25.56.1, systemd-mini-210.1484047020.83cb8e58d-25.56.1

openSUSE-RU-2017:0213-1: An update that has 13 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1012390,1012591,1012818,1013989,1015515,1018214,1018399,909418,912715,945340,953807,963290,990538
CVE References: 
Sources used:
openSUSE Leap 42.2 (src):    systemd-228-19.1, systemd-mini-228-19.1

SUSE-RU-2017:0692-1: An update that has 16 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1001790,1005404,1005497,1012266,1012591,1013989,1018399,1020083,909418,912715,945340,963290,964168,968183,990538,997682
CVE References: 
Sources used:
SUSE Linux Enterprise Server for SAP 12 (src):    systemd-210-70.61.5
SUSE Linux Enterprise Server 12-LTSS (src):    systemd-210-70.61.5

SUSE-RU-2017:0693-1: An update that has 11 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1012266,1012591,1013989,1018399,1020083,909418,912715,945340,963290,990538,997682
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP1 (src):    systemd-210-116.6.6
SUSE Linux Enterprise Server 12-SP1 (src):    systemd-210-116.6.6
SUSE Linux Enterprise Desktop 12-SP1 (src):    systemd-210-116.6.6

openSUSE-RU-2017:0789-1: An update that has 11 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1012266,1012591,1013989,1018399,1020083,909418,912715,945340,963290,990538,997682
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    systemd-210-104.1, systemd-mini-210-104.1

(In reply to Takashi Iwai from comment #4)
> Didn't you see this behavior earlier?

I just found bug 696851 (openSUSE 11.4).

(In reply to Franck Bui from comment #41)
> Closing as it should be fixed by the next update.

Problem still present on openSUSE Leap 42.3 (kernel 4.4.143-65-default)!
My "CD-ROM" drive is actually a BluRay Writer (in case it matters):

  Model: "HL-DT-ST BD-RE  BH10LS30"
  Vendor: "HL-DT-ST"
  Device: "BD-RE  BH10LS30"
  Revision: "1.01"
  Driver: "ahci", "sr"
  Driver Modules: "ahci", "sr_mod"

As the kernel thinks the medium is still mounted (and thus online), an access to the mounted directory cause errors like this (the tray actually still IS open):
Aug 25 21:40:22 i7g4x4a kernel: sr 2:0:0:0: [sr0] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 25 21:40:22 i7g4x4a kernel: sr 2:0:0:0: [sr0] tag#11 Sense Key : Not Ready [current] 
Aug 25 21:40:22 i7g4x4a kernel: sr 2:0:0:0: [sr0] tag#11 Add. Sense: Medium not present - tray open
Aug 25 21:40:22 i7g4x4a kernel: sr 2:0:0:0: [sr0] tag#11 CDB: Read(10) 28 00 00 00 00 1f 00 00 01 00
Aug 25 21:40:22 i7g4x4a kernel: blk_update_request: I/O error, dev sr0, sector 124

Maybe if the kernel allows ejecting a device that is open (mounted), a callback should "umount" (close) the device.
Still I think that ejecting a mounted medium should not be possible in the non-emergency case. GUIs could pop up a message box saying that the request to unmount/eject the device was denied as there a files being used still.
Why should an optical medium be so much different from some disk medium?

(In reply to Ulrich Windl from comment #55)

> Maybe if the kernel allows ejecting a device that is open (mounted), a
> callback should "umount" (close) the device.

Yes. Hence Takashi's suggestion in comment #6

> Still I think that ejecting a mounted medium should not be possible in the
> non-emergency case. GUIs could pop up a message box saying that the request
> to unmount/eject the device was denied as there a files being used still.
> Why should an optical medium be so much different from some disk medium?

1. It is read only
2. That is what other OSes do (let's be honest)
3. We generally presume the user knows what his doing
4. If the drive is external, the user can just unplug it

(In reply to Ulrich Windl from comment #54)
> Problem still present on openSUSE Leap 42.3 (kernel 4.4.143-65-default)!
> My "CD-ROM" drive is actually a BluRay Writer (in case it matters):
> 

what does "udevadm info /dev/xxx" show for this device ?

Ulrich, can you please provide the info (see comment #57) otherwise I'll have to close the bug.

(In reply to Franck Bui from comment #57)
> what does "udevadm info /dev/xxx" show for this device ?

# udevadm info /dev/sr0 
P: /devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr0
N: sr0
L: -100
S: cdrom
S: cdrw
S: disk/by-id/ata-HL-DT-ST_BD-RE_BH10LS30_K9JB37M1915
S: disk/by-label/XPLANE9
S: disk/by-path/pci-0000:00:1f.2-ata-3
S: disk/by-uuid/2009-08-16-14-11-48-00
S: dvd
S: dvdrw
E: DEVLINKS=/dev/disk/by-uuid/2009-08-16-14-11-48-00 /dev/dvd /dev/cdrw /dev/dvdrw /dev/disk/by-path/pci-0000:00:1f.2-ata-3 /dev/disk/by-label/XPLANE9 /dev/disk/by-id/ata-HL-DT-ST_BD-RE_BH10LS30_K9JB37M1915 /dev/cdrom
E: DEVNAME=/dev/sr0
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr0
E: DEVTYPE=disk
E: ID_ATA=1
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=0
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_BUS=ata
E: ID_CDROM=1
E: ID_CDROM_BD=1
E: ID_CDROM_BD_R=1
E: ID_CDROM_BD_RE=1
E: ID_CDROM_CD=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_DVD_PLUS_R=1
E: ID_CDROM_DVD_PLUS_RW=1
E: ID_CDROM_DVD_PLUS_R_DL=1
E: ID_CDROM_DVD_R=1
E: ID_CDROM_DVD_RAM=1
E: ID_CDROM_DVD_RW=1
E: ID_CDROM_MEDIA=1
E: ID_CDROM_MEDIA_DVD=1
E: ID_CDROM_MEDIA_SESSION_COUNT=1
E: ID_CDROM_MEDIA_STATE=complete
E: ID_CDROM_MEDIA_TRACK_COUNT=1
E: ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_FOR_SEAT=block-pci-0000_00_1f_2-ata-3
E: ID_FS_APPLICATION_ID=TOAST\x20ISO\x209660\x20BUILDER\x20COPYRIGHT\x20\x28C\x29\x201997-2005\x20SONIC\x20SOLUTIONS\x20-\x20HAVE\x20A\x20NICE\x20DAY
E: ID_FS_LABEL=XPLANE9
E: ID_FS_LABEL_ENC=XPLANE9
E: ID_FS_SYSTEM_ID=APPLE\x20COMPUTER\x2c\x20INC.\x2c\x20TYPE:\x200002
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=2009-08-16-14-11-48-00
E: ID_FS_UUID_ENC=2009-08-16-14-11-48-00
E: ID_FS_VERSION=Joliet Extension
E: ID_MODEL=HL-DT-ST_BD-RE_BH10LS30
E: ID_MODEL_ENC=HL-DT-ST\x20BD-RE\x20\x20BH10LS30\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_PATH=pci-0000:00:1f.2-ata-3
E: ID_PATH_TAG=pci-0000_00_1f_2-ata-3
E: ID_REVISION=1.01
E: ID_SCSI=1
E: ID_SCSI_INQUIRY=1
E: ID_SERIAL=HL-DT-ST_BD-RE_BH10LS30_K9JB37M1915
E: ID_SERIAL_SHORT=K9JB37M1915
E: ID_TYPE=cd
E: ID_VENDOR=HL-DT-ST
E: ID_VENDOR_ENC=HL-DT-ST
E: MAJOR=11
E: MINOR=0
E: SCSI_MODEL=BD-RE_BH10LS30
E: SCSI_MODEL_ENC=BD-RE\x20\x20BH10LS30\x20
E: SCSI_REVISION=1.01
E: SCSI_TPGS=0
E: SCSI_TYPE=cd/dvd
E: SCSI_VENDOR=HL-DT-ST
E: SCSI_VENDOR_ENC=HL-DT-ST
E: SUBSYSTEM=block
E: TAGS=:seat:systemd:uaccess:
E: USEC_INITIALIZED=22907809

(In reply to Ulrich Windl from comment #59)
> # udevadm info /dev/sr0 

For some reasons SYSTEMD_MOUNT_DEVICE_BOUND=1 is not defined whereas ID_CDROM=1 is...

Can you run the following commands and report back their output ?

 $ rpm -q --changelog udev | grep 909418

 $ systemd-delta

Thanks.

(In reply to Franck Bui from comment #60)
> Can you run the following commands and report back their output ?
>  $ rpm -q --changelog udev | grep 909418
### I guess you could inspect udev-228-53.1.x86_64 also...
# rpm -q --changelog udev | grep 909418
  1a25ebe78 core: make mount units from /proc/self/mountinfo possibly bind to a device (#4515) (boo#909418 bsc#912715 bsc#945340)

> 
>  $ systemd-delta
### More interesting (note the date!):
[EQUIVALENT] /etc/sysctl.d/99-sysctl.conf → /usr/lib/sysctl.d/99-sysctl.conf
[EXTENDED]   /usr/lib/systemd/system/systemd-sysctl.service → /usr/lib/systemd/system/systemd-sysctl.service.d/50
[EXTENDED]   /usr/lib/systemd/system/nfs-client.target → /usr/lib/systemd/system/nfs-client.target.d/nfs.conf
[EXTENDED]   /usr/lib/systemd/system/nfs-server.service → /usr/lib/systemd/system/nfs-server.service.d/nfsserver.
[EXTENDED]   /usr/lib/systemd/system/nfs-config.service → /usr/lib/systemd/system/nfs-config.service.d/restart.co
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/udev/rules.d/60-cdrom_id.rules → /usr/lib/udev/rules.d/60-cdrom_id.rules

--- /usr/lib/udev/rules.d/60-cdrom_id.rules     2018-08-16 16:15:22.000000000 +0200
+++ /etc/udev/rules.d/60-cdrom_id.rules 2014-11-27 15:46:01.000000000 +0100
@@ -8,10 +8,6 @@
 # unconditionally tag device as CDROM
 KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"
 
-# stop automatically any mount units bound to the device if the media eject
-# button is pressed.
-ENV{ID_CDROM}=="1", ENV{SYSTEMD_MOUNT_DEVICE_BOUND}="1"
-
 # media eject button pressed
 ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"
 
@@ -19,12 +15,6 @@
 # enable the receiving of media eject button events
 IMPORT{program}="cdrom_id --lock-media $devnode"
 
-# ejecting a CD does not remove the device node, so mark the systemd device
-# unit as inactive while there is no medium; this automatically cleans up of
-# stale mounts after ejecting
-ENV{DISK_MEDIA_CHANGE}=="?*", ENV{ID_CDROM_MEDIA}!="?*", ENV{SYSTEMD_READY}="0"
-
-KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"
 KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"
 KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", OPTIONS+="link_priority=-100"
 KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", OPTIONS+="link_priority=-100"


7 overridden configuration files found.
#### From my personal history, I guess I updated from 13.1 to 13.2 on 29. Nov 2014 ;-)

Looking it up in Google, I found that these lines that are missing were  committed Dec 16, 2016 (https://github.com/systemd/systemd/commit/ebc8968bc0b6fc460099041f5ae1262ca17eeb6e), so the openSUSE update missed to fix the old files (And obviously I couldn't have deleted those lines in 2014 when they were added 2016 ;-)).

Strange because on my openSUSE 13.1/13.2 setups, both cases show that the rule file is installed at the correct place:

 # rpm -ql udev | grep 60-cdrom
 /usr/lib/udev/rules.d/60-cdrom_id.rules

and no rule file installed in /etc...

So I cannot think to a reason why 60-cdrom_id.rules has been copied in /etc in your case.

Anyway this would be a different bug so I'm closing this one again.

If anyone encounters the same issue, a new bug report should be created.