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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018å¹´03æ??01æ?¥ 17:50, Lennart Poettering wrote:
> On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.song at windriver.com) wrote:
>
>> Thank you very much. It dose work.
>>
>> Would you tell me that how the '--no-block' works,
> "systemd-mount" talks to systemd (i.e. PID 1) to issue mount/automount
> operations. By default it will do so synchronously, thus blocking
> until the mount is established. If you specify "--no-block" then you
> turn off this synchronous behaviour, and instead request asynchronous
> behaviour, where the rule will just request the operation to be
> executed, but won't wait for it to finish. When you invoke
> "systemd-mount" from a udev rule then using "--no-block" is a
> necessity to avoid a deadlock. That's because PID 1 won't operate on a
> device to mount before udev reported it to be fully availabled and
> probed.
Do you mean that udev doesn't report device to be fully availabled
and probed until systemd-mount returns?

Thank you for your selfless help.
Hongzhi.Song
> Now, if synchronously wait for that from inside the udev rule
> you hence delay precisely that probing forever.
>
>> I doesn't deeply understand the interpretation in
>>
>> https://www.freedesktop.org/software/systemd/man/systemd-mount.html#SYSTEMD_MOUNT_OPTIONS=
>>
>>
>> And why systemd-mount can solve the problem brought by MountFlag=slave.
> systemd-mount request the mount operation to be executed by PID 1, and
> hence outside of the mount context of udev.
>
> Lennart
>



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux