On Do, 22.02.18 20:52, Hongzhi, Song (hongzhi.s...@windriver.com) wrote:
> Hi,
>
> systemd, upstream commit id c2c13f2df42e0691aecabe3979ea81cd7faa35c7
>
> You set MountFlags=slave just for keeping mounts done by udev rules private
> to udevd.
>
> So all block device mounted by systemd-udevd is unvisible for host.
>
> I don't know why. And is there any bad effect, if I change slave to shared ?
Well, we generally try to run all our services with sandboxes that are
as tight as we can make them. udev can run arbitrary stuff from its
rules hence the sandbox can't be made too tight unfortunately.
MountFlags=slave is essentially a sandboxing setting: it detaches
mount() operations done within the service from the rest of the
system.
While udev rules can do pretty much everything, we do know that doing
mount operations themselves is not the best of ideas, and there are
better approaches. That's because udev rules should be quick, and
mounting isn't necessarily (in particular on dirty fs).
Specifcally, there are three schemes that are much preferable:
1. Use TAG+="systemd", ENV{SYSTEMD_WANTS}+="foobar.mount" in udev
rules to asynchronously pull in mount units from udev rules.
2. Invoke "systemd-mount" from udev rules, which will spawn transient
automount and mount units for devices. This is generally the best
way in particular in embedded applications to deal with
hotpluggable media. It optionally runs fsck before mounting for
you, and it it uses automounts for keeping the actual window when a
device is mounted as brief as possible, in order to maximize the
chance that the file system remains in a fully clean state, since
it's essentially unmounted whenever idle. If you have hotplug media
this means you get the best chance of leaving the fs in a clean
state, and getting it back into a clean state if it evers gets into
an unclean state.
3. Use a daemon such as udisks to manage hotplugs of devices.
That all said, you can also deviate from upstream and simply drop the
MountFlags=slave, but of course, this means you lose compatibility
with upstream on this.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
