[systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in

Hongzhi, Song hongzhi.song at windriver.com
Tue Feb 27 14:20:59 UTC 2018


Hi,

thank for your help, but I still have some question.


My current linux system init uses systemd and udev, with 
'automount.rules' and 'mount.sh' in /etc/udev/,

to manage device. But owning to MountFlags=slave, hotpluggable media 
(e.g., /dev/sda1 )

can be mounted again in host, whereas can't be formatted by mkfs.ext4 in 
host with error

message '/dev/sda1 is apparently in use by the system; will not make a 
filesystem here!'.


In your reply, you told me to invoke "systemd-mount" from udev rules. Do 
you mean that

I should replace /bin/mount with /usr/bin/systemd-mount in mount.sh, or add

"RUN+='/usr/bin/systemd-mount $env{DEVNAME}'" to automount.rules?

1)

I  replaced /bin/mount with /usr/bin/systemd-mount in mount.sh.

     /usr/bin/systemd-mount $DEVNAME "/run/media/$name"

it prompted that

     systemd[1]: dev-sda.device: Job dev-sda.device/start timed out.
     systemd[1]: Timed out waiting for device dev-sda.device.
     systemd[1]: Dependency failed for /run/media/sda.
     systemd[1]: run-media-sda.mount: Job run-media-sda.mount/start 
failed with result 'dependency'.
     systemd[1]: Dependency failed for File System Check on /dev/sda.
     systemd[1]: systemd-fsck at dev-sda.service: Job 
systemd-fsck at dev-sda.service/start failed with result 'dependency'.
     systemd[1]: Startup finished in 16.692s (kernel) + 1min 32.605s 
(userspace) = 1min 49.298s.
     systemd[1]: dev-sda.device: Job dev-sda.device/start failed with 
result 'timeout'.

     ...

in /var/log/syslog.

2)

I edited automount.rules with "SUBSYSTEM=="block", ACTION=="add"    
RUN+="/usr/bin/systemd-mount $env{DEVNAME}",

it prompt that "systemd-udevd Process '/usr/bin/systemd-mount 
$env{DEVNAME}' failed with exit code 1".


Infact, my problem is that I can't format /dev/sda1 with mkfs.ext4 in 
host with MountFlags=slave.

So. is it usefull to use systemd-mount? If it is, how should do to fix 
the new problems mentioned above.


Thanks again for your help.


On 2018年02月23日 19:06, Lennart Poettering wrote:
> On Do, 22.02.18 20:52, Hongzhi, Song (hongzhi.song at 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
>



More information about the systemd-devel mailing list