Re: How to coordinate a DVD burn program with udev ?

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i managed to work around the problem - at least on my system.

There are at least two oddities involved

- If the kernel events happen, then always on open().
  But it is quite unpredictable whether they happen at all.
  xorriso and program "eject" have a higher probability to trigger
  kernel events than wodim.
  (Watched by: udevadm monitor --kernel )

- udev patience is between 4 and 7 seconds.
  4 seconds and a kernel event can trigger link vanishing even if the
  tray was already loaded. 7 seconds and kernel event happen only if
  the tray had to be loaded and thus the xorriso run needed long enough.
  Program "eject" does not run that long and causes no vanishing.
  Possibly it does not block out udev, anyway.

An accordingly odd workaround in libburn looks like:

  fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);
  if (fd >= 0) {
          close(fd);
          usleep(2000000);
          fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);
  }

instead of simply

  fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);

O_EXCL on /dev/sr0 is supposed to block out any other open() which
uses O_EXCL itself. (Not a POSIX feature.)
It might be a decisive ingredient for the mess, but it is the only
halfways reliable means to coordinate burn programs so that they
do not use the same drive.

It is still unclear why wodim's open() triggers much fewer kernel
events than the one of libburn.
But above workaround has a similar effect.

After triggering a kernel event with my workaround once, the probability
gets significantly lower for kernel events to be caused by old libburn. 
But it is still not 0.

---------------------------------------------------------------

I would still like to discuss the unpredictability of kernel events
and the harsh reaction of udev on inaccessible drives.
The workaround is actually a race condition. It might break with the
next change in kernel or udev.


Have a nice day :)

Thomas