On Thu, Sep 18, 2014 at 8:22 AM, Hoyer, Marko (ADITG/SW2)
<mho...@de.adit-jv.com> wrote:
> Hello together,
> I recently stumbled over cdrom_id opening the device with the O_EXCL flag 
> set, if it is not currently mounted:
> "fd = open(node, O_RDONLY|O_NONBLOCK|(is_mounted(node) ? 0 : O_EXCL));"
> The effect of this is that automatically mounting a cdrom sometimes results 
> in "resource busy", if "change" uevents of the devices are processed by udevd 
> while the automounter (udisks or something different in my case) is currently 
> trying to mount the device triggered by a previous "add" or "change" uevent.
> I've to questions to this issue. Maybe someone of you can help me:
> 1. Is there any particular reason why cdrom_id should open the device 
> exclusively (especially since it is not opened exclusively when it is already 
> mounted)?
> 2. If there is any good reason to keep this behavior: How is the best way for 
> an automounter to deal with this? Retry? Something different?

This was introduced in:

commit 38a3cde11bc77af49a96245b8a8a0f2b583a344c
Author: Kay Sievers <kay.siev...@vrfy.org>
Date:   Thu Mar 18 11:14:32 2010 +0100

    cdrom_id: open non-mounted optical media with O_EXCL

    This should prevent confusing drives during CD burning sessions. Based
    on a patch from Harald Hoyer.

According to this commit we use O_EXCL to not confuse burning-sessions
that might run in parallel. Admittedly, burning-sessions should
usually open the device themselves via O_EXCL, or lock critical
sections via scsi, but I guess back in the days we had to work around
bugs in other programs (or I may be missing something non-obvious; I'm
not that much into scsi..).

Regarding what do to: If you deal with cdrom devices and get EBUSY,
I'd simply ignore the device. In case of udev, you get a uevent once
udev is done, and usually that means the device changed in some way so
it's *good* you wait for it to be processed. So your automounter will
get a uevent once udev is done and can then try to mount the device.

systemd-devel mailing list

Reply via email to