Hey Lennart, Lennart Poettering [2015-01-27 0:55 +0100]: > Hmm? I don't see how mount propagation would break 60-cdrom_id... The > eject ioctl operates on the device node, and does not care for > mounts. This problem sounds made-up to me.
Right now cdrom_id indeed wouldn't be affected as it doesn't unmount a CD which is about to ejected. That's the very problem that was recently discussed here: http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html The two proposed solutions were to either teach cdrom_id --eject to umount the device or just call the actual "eject" program which gets this pretty much right. But neither would work because of the unshared mount ns in udev. > Moreover, if you want to do mounts or umounts on plug or play, then > use a proper daemon, like udisks. udisks actually used to have both the CD-ROM polling (which since then moved into the kernel) and the post-eject cleanup. If we want to keep the udev mount unsharing, we could put it back into udisks; but that wouldn't be that robust as udisks isn't guaranteed to actually run, both because it's a D-BUS activated service and a lot of server-ish machines or lightweight desktops don't even have it. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel