[systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

[Dave Reisner]

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