Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
On Fr, 02.03.18 10:22, Hongzhi, Song (hongzhi.s...@windriver.com) wrote: > On 2018年03月01日 17:50, Lennart Poettering wrote: > > On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@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? Yes. All programs configured in udev rules files need to finish before udev reports the device to its clients to be fullyprobed and ready. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
On 2018年03月01日 17:50, Lennart Poettering wrote: On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@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. 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
Thank you very much. It dose work.
Would you tell me that how the '--no-block' works,
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.
Best Regard,
Hongzhi
On 2018年02月28日 03:02, Andrei Borzenkov wrote:
27.02.2018 17:20, Hongzhi, Song пишет:
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@dev-sda.service: Job
systemd-fsck@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.
Try
systemd-mount --no-block ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
27.02.2018 17:20, Hongzhi, Song пишет:
> 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@dev-sda.service: Job
> systemd-fsck@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.
>
Try
systemd-mount --no-block ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
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@dev-sda.service: Job
systemd-fsck@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.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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
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
[systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in
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 ? Thanks for your help. BR， Hongzhi.Song ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
