This reverts part of c2c13f2df42e0, which introduced this with no explanation as to *why*. Enslaving the mount namespace breaks default behavior included in rules/60-cdrom_id.rules. Specifically, filesystems on optical media will not be properly unmounted when the physical eject button is used in the absence of a helper tool like udisks2.
This was discussed here: http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html And has been reported to several bug trackers: https://bugs.archlinux.org/task/42071 http://bugzilla.opensuse.org/show_bug.cgi?id=909418 https://bugs.freedesktop.org/bugzilla/show_bug.cgi?id=72206 --- I'm guessing that the rationale for the breaking commit was dissuading users from calling mount(8) from udev rules, but I don't think that's a good enough reason to break users who don't use udisks and still rely on optical media. More to the point, do we really need to patch around bad users? Other than mount(8) hanging and tying up a udevd worker (which will eventually be killed by the cgroup cleanup logic), what's the actual harm that comes from mounting via a udev rule? units/systemd-udevd.service.in | 1 - 1 file changed, 1 deletion(-) diff --git a/units/systemd-udevd.service.in b/units/systemd-udevd.service.in index f6acd6f..57ea5f7 100644 --- a/units/systemd-udevd.service.in +++ b/units/systemd-udevd.service.in @@ -21,4 +21,3 @@ Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket Restart=always RestartSec=0 ExecStart=@rootlibexecdir@/systemd-udevd -MountFlags=slave -- 2.2.2 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
