Discussion:
Why did you set MountFlags=slave in systemd-udevd.service.in
(too old to reply)
Hongzhi, Song
2018-02-22 12:52:26 UTC
Permalink
Raw Message
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
Lennart Poettering
2018-02-23 11:06:04 UTC
Permalink
Raw Message
Post by Hongzhi, Song
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
Hongzhi, Song
2018-02-27 14:20:59 UTC
Permalink
Raw Message
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-***@dev-sda.service: Job
systemd-***@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.
Post by Lennart Poettering
Post by Hongzhi, Song
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).
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
Andrei Borzenkov
2018-02-27 19:02:19 UTC
Permalink
Raw Message
Post by 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]: 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 ...
Hongzhi, Song
2018-03-01 06:44:20 UTC
Permalink
Raw Message
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
Post by Andrei Borzenkov
Post by 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]: 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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2018-03-01 09:50:53 UTC
Permalink
Raw Message
Post by Hongzhi, Song
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.
Post by Hongzhi, Song
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
Hongzhi, Song
2018-03-02 02:22:36 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Hongzhi, Song
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
Post by Lennart Poettering
Now, if synchronously wait for that from inside the udev rule
you hence delay precisely that probing forever.
Post by Hongzhi, Song
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
2018-03-02 09:02:27 UTC
Permalink
Raw Message
Post by Hongzhi, Song
Post by Lennart Poettering
Post by Hongzhi, Song
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
Loading...