Hi
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.
Thanks
David
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
