> -----Original Message----- > From: David Herrmann [mailto:dh.herrm...@gmail.com] > Sent: Thursday, September 18, 2014 10:31 AM > To: Hoyer, Marko (ADITG/SW2) > Cc: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] cdrom_id opens device with O_EXCL, why? > > 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
Thx for the answer. The automounter is listening to the udev socket so it is actually waiting for the event to be processed completely. But unfortunately, it appears that sequences of change events might come in a short time frame. So the automounter is trying to mount the device triggered by the first one, while udevd is currently processing the second one. That's what's happening actually in my case. Besides that the issue with cdrom_id not working in case of a lazy unmount (described in my second mail) seems to me to be a bit more critical. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
