Comment 11 for bug 581404

I'm having a similar problem.

I'm running Ubuntu 10.04 LTS with kernel 2.6.38-14-generic-pae.
I use growisofs nightly for incremental backups, and call eject for the device upon successful completion.
For the last month or so, the eject I call from the nightly backup script (from root) seemed to have always failed to eject even though "eject" completes successfully (exit code 0). Repeated calls to eject from the script behave the same. Yet if I do it from my ordinary user account from the shell, it always works.

But I think what is actually happening is that the cdrom is successfully ejected, but a little more than 10 mins later, the cdrom drive reloads all by itself. (So when I look, hours later, the cdrom is not ejected.) Anyway, to check this I've just done the udevadm followed by eject /dev/sr0, at Wed Jul 25 14:44:30 EST 2012. I'm now waiting to see if it reloads by itself in 10 mins or so. Here's the output for the eject response:

# udevadm monitor -e --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV [1343191466.465788] change /devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0
SUBSYSTEM=block
DISK_MEDIA_CHANGE=1
DEVNAME=/dev/sr0
DEVTYPE=disk
SEQNUM=2368
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RW=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_SCSI=1
ID_VENDOR=hp
ID_VENDOR_ENC=hp\x20\x20\x20\x20\x20\x20
ID_MODEL=DVD-RAM_GH80N
ID_MODEL_ENC=DVD-RAM\x20GH80N\x20\x20\x20
ID_REVISION=RF03
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:11.0-scsi-2:0:0:0
ACL_MANAGE=1
GENERATED=1
UDISKS_PRESENTATION_NOPOLICY=0
MAJOR=11
MINOR=0
DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0 /dev/cdrom /dev/cdrw /dev/dvd /dev/dvdrw

Ah ha. Yes, at 14:54 it reloaded all by itself. Here's the udevadm output:

UDEV [1343192084.987298] change /devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0
SUBSYSTEM=block
DISK_MEDIA_CHANGE=1
DEVNAME=/dev/sr0
DEVTYPE=disk
SEQNUM=2370
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RW=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD_RW=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_SCSI=1
ID_VENDOR=hp
ID_VENDOR_ENC=hp\x20\x20\x20\x20\x20\x20
ID_MODEL=DVD-RAM_GH80N
ID_MODEL_ENC=DVD-RAM\x20GH80N\x20\x20\x20
ID_REVISION=RF03
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:11.0-scsi-2:0:0:0
ID_FS_LABEL=2.0.00
ID_FS_LABEL_ENC=2.0.00
ID_FS_TYPE=udf
ID_FS_USAGE=filesystem
ACL_MANAGE=1
GENERATED=1
FSTAB_NAME=/dev/scd0
FSTAB_DIR=/media/cdrom0
FSTAB_TYPE=udf,iso9660
FSTAB_OPTS=user,noauto,exec,utf8
FSTAB_FREQ=0
FSTAB_PASSNO=0
UDISKS_PRESENTATION_NOPOLICY=0
MAJOR=11
MINOR=0
DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0 /dev/disk/by-label/2.0.00 /dev/cdrom /dev/cdrw /dev/dvd /dev/dvdrw

I don't suppose there's any chance that the manufacturer (HP) has decided that cooling the PC doesn't work properly if the cdrom drive door is open, so has some sort of in-device firmware that somehow forces a close after 10 mins?