Discussion:
Again, why this strange behavior implied by "auto" in fstab ?
Add Reply
Franck Bui
2018-01-23 14:47:21 UTC
Reply
Permalink
Raw Message
Hi,

I'm resurrecting an old but recurrent issue here which I'd like to
clarify one more time.

Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.

However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.

And this part confuses a lot of users since fstab has always been used
to list filesystems that should be mounted during the boot process
only. It has never been the place used by disk managers to list
mount-points that should be automatically mounted after the system
booted.

Furthermore, it complicates the disk administrative tasks because now
one needs to be careful when it creates and initialize partitions
because systemd can mount the partition on the back of the user. We
recently had one such bug report (again).

According to Lennart[1], this feature is there because:

"mount it if it is around at boot, but not later" is not
available, since the idea is not compatible with modern
storage.

I'm not sure why the old behavior is not compatible with modern
storage but with the following trivial change:

static bool mount_is_auto(const MountParameters *p) {
assert(p);

- return !fstab_test_option(p->options, "noauto\0");
+ return fstab_test_option(p->options, "auto\0");
}

it seems to me that it could have the best of both worlds.

The change basically redefines the meaning of "auto" option, which I
assumed was introduced by systemd since only "noauto" is described in
fstab(5) man page.

"auto" is used to enable the magic/odd feature "mount a filesystem
(listed in fstab) every times its backend device appears. This can
happen during the boot process or any time later". And this option is
assumed by default.

With the above change "auto" wouldn't affect the boot process: the
filesystem would be mounted during the boot process as usual unless
"noauto" is used. However if "auto" is not used, the magic feature is
disabled. And this would be the default.

This should meet most users expectations: by default a filesystem
listed in fstab is mounted during the boot process only once. No more
magic after.

If "nofail" is used, then PID1 wouldn't wait for the device to appear
during the boot process and would leave the mount unit waiting in the
background until the device appears or a timeout expires. But the
mount unit wouldn't be started automatically if the device appears
once the timeout has expired.

So the question is now: "what am I missing ?"

Thanks.

[1]
https://lists.freedesktop.org/archives/systemd-devel/2014-August/022285.html
Simon McVittie
2018-01-23 15:49:31 UTC
Reply
Permalink
Raw Message
Post by Franck Bui
Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.
However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.
Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?

If you don't want systemd to do its best to ensure that a particular
filesystem is always mounted, please add the noauto option to it. In the
absence of noauto, consumers of fstab (including udev and systemd) assume
that you want this filesystem mounted at all times (between early startup
and late shutdown), and will get as close to that as is achievable.
Post by Franck Bui
[fstab] has never been the place used by disk managers to list
mount-points that should be automatically mounted after the system
booted
That's not true, some dynamic disk managers outside systemd (at least
udisks) do respect configuration in fstab.
Post by Franck Bui
I'm not sure why the old behavior is not compatible with modern
storage
The traditional behaviour requires you to have a well-defined point during
boot at which you know that all hardware that was attached at power-on has
been detected, and all hardware that subsequently appears was hot-plugged
and should go through a different code path; but with modern buses
(most visibly USB, but also buses that you probably think of as more
static than they really are), there is no time at which you can know
that all hardware that was attached at power-on has now been detected.

It would be possible to use an arbitrary timeout, but arbitrary timeouts
are a problematic design: either they're too short and they unpredictably
miss some initially-attached hardware, or they're too long and they
arbitrarily slow down everyone's boot process, or (more likely) both
failure modes at the same time for different people.

smcv
Reindl Harald
2018-01-23 15:54:28 UTC
Reply
Permalink
Raw Message
Post by Simon McVittie
Post by Franck Bui
Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.
However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.
Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?
with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto"
mount-point in peace and spits the "Failed to read symlink target for
/mnt/arrakis: Permission denied" for fuse-mountpoints multiple times
each day into the systemlogs (systemd-234-9.fc27.x86_64)

[***@srv-rhsoft:~]$ systemctl daemon-reload

[***@srv-rhsoft:~]$ cat messages
Jan 23 16:52:16 srv-rhsoft systemd-fstab-generator[27644]: Failed to
read symlink target for /mnt/arrakis: Permission denied

[***@srv-rhsoft:~]$ cat /etc/fstab | grep /mnt/arrakis
sshfs#***@arrakis:/
/mnt/arrakis fuse
noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry
Mike Gilbert
2018-01-23 19:09:16 UTC
Reply
Permalink
Raw Message
Post by Reindl Harald
Post by Simon McVittie
Post by Franck Bui
Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.
However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.
Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?
with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto"
mount-point in peace and spits the "Failed to read symlink target for
/mnt/arrakis: Permission denied" for fuse-mountpoints multiple times each
day into the systemlogs (systemd-234-9.fc27.x86_64)
Jan 23 16:52:16 srv-rhsoft systemd-fstab-generator[27644]: Failed to read
symlink target for /mnt/arrakis: Permission denied
noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry
Sounds like you have a broken symlink at /mnt or /mnt/arrakis. systemd
is trying to deference said symlink when it generates the mount unit
for that fstab entry.

There's an explanation for this in the commit that introduced the behavior.

https://github.com/systemd/systemd/commit/634735b56b82bdde3c67193ba7b470bab80fdcbd
Reindl Harald
2018-01-23 23:59:51 UTC
Reply
Permalink
Raw Message
Post by Mike Gilbert
Post by Reindl Harald
Post by Simon McVittie
Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?
with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto"
mount-point in peace and spits the "Failed to read symlink target for
/mnt/arrakis: Permission denied" for fuse-mountpoints multiple times each
day into the systemlogs (systemd-234-9.fc27.x86_64)
Jan 23 16:52:16 srv-rhsoft systemd-fstab-generator[27644]: Failed to read
symlink target for /mnt/arrakis: Permission denied
noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry
Sounds like you have a broken symlink at /mnt or /mnt/arrakis. systemd
is trying to deference said symlink when it generates the mount unit
for that fstab entry
no - it's how fuse-mountpoints simply work

nobody but the user which mounted is has access and hence systemd should
leave fuse-mountpoints with "noauto" completly in peace as well as any
"noauto" stuff or manual mounted filesystems

you can see mount-unit failures on CentOS7 as example when you unmount
your manually mounted luks-on-raid10 storage with no entry in fstab at all

[***@srv-rhsoft:~]$ stat /mnt/arrakis
stat: cannot stat '/mnt/arrakis': Permission denied

[***@srv-rhsoft:~]$ stat /mnt/arrakis
File: /mnt/arrakis
Size: 16384 Blocks: 32 IO Block: 4096 directory
Device: 48h/72d Inode: 1 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 500/ harry) Gid: ( 501/verwaltung)
Access: 2018-01-23 21:15:02.000000000 +0100
Modify: 2017-12-21 15:07:12.000000000 +0100
Change: 2017-12-21 15:07:12.000000000 +0100
Birth: -
Lennart Poettering
2018-01-24 14:50:10 UTC
Reply
Permalink
Raw Message
Post by Reindl Harald
Post by Simon McVittie
Post by Franck Bui
Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.
However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.
Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?
with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto"
mount-point in peace and spits the "Failed to read symlink target for
/mnt/arrakis: Permission denied" for fuse-mountpoints multiple times each
day into the systemlogs (systemd-234-9.fc27.x86_64)
Yeah, FUSE is weird. It exposes mount points that root can't
access. I am note sure how we could safely detect such mounts in a
non-ugly way though (as statvfs() on such mounts won't work), and I am
not sure we should downgrade EACCES log messages in a blanket fashion
since usually they indicate MAC issues, that shouldn't be ignored...

We do generate mount units for all mount points listed in /etc/fstab
unconditionally. This is so that RequiresMountsFor= can work for them
and such. Specifying "noauto" doesn't mean "don't generate mount units
at all". It just means "don't pull them explicitly into the initial
transaction".

Anyway, please file a github issue, we should do something about this.

(That said, this is entirely unrelated to Franck's point AFAICS)

Lennart
--
Lennart Poettering, Red Hat
Thomas Blume
2018-01-24 13:51:19 UTC
Reply
Permalink
Raw Message
Post by Simon McVittie
Post by Franck Bui
I'm not sure why the old behavior is not compatible with modern
storage
The traditional behaviour requires you to have a well-defined point during
boot at which you know that all hardware that was attached at power-on has
been detected, and all hardware that subsequently appears was hot-plugged
and should go through a different code path; but with modern buses
(most visibly USB, but also buses that you probably think of as more
static than they really are), there is no time at which you can know
that all hardware that was attached at power-on has now been detected.
It would be possible to use an arbitrary timeout, but arbitrary timeouts
are a problematic design: either they're too short and they unpredictably
miss some initially-attached hardware, or they're too long and they
arbitrarily slow down everyone's boot process, or (more likely) both
failure modes at the same time for different people.
Suppressing the auto mount when a device (re)appears, is usually desired
during some administrative tasks.
What about lowering the hurdle for administrators by introducing a new
systemctl command?

Maybe something like:

systemctl lock $DEVICE

We could write the name of $DEVICE in some directory below /run/systemd.
An udev rule could parse this directory when an add event for a device
occurres and if $DEVICE matches, it could set SYSTEMD_READY=0.
We would only need to make sure that SYSTEMD_READY gets reset back to 1 at an:

systemctl unlock $DEVICE

That shouldn't be too hard to code either.

Would this be an acceptable approach?

Regards
Thomas
Lennart Poettering
2018-01-24 14:13:24 UTC
Reply
Permalink
Raw Message
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.

It's a bit underdocumented, but it's the right way, doesn't leave
artifacts in the system around and uses the appropriate OS primitives
for what it needs to do.

If you need this in shell, then I figure util-linux' flock tool should
be something you can make work, as it appears to be a command line
wrapper around BSD file locks.

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2018-01-24 19:01:54 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.
How exactly is udev relevant here? This discussion has nothing to do
with udev.
Post by Lennart Poettering
It's a bit underdocumented, but it's the right way, doesn't leave
artifacts in the system around and uses the appropriate OS primitives
for what it needs to do.
If you need this in shell, then I figure util-linux' flock tool should
be something you can make work, as it appears to be a command line
wrapper around BSD file locks.
Lennart
Lennart Poettering
2018-01-24 19:08:36 UTC
Reply
Permalink
Raw Message
On Mi, 24.01.18 22:01, Andrei Borzenkov (***@gmail.com) wrote:
1;5002;0c
Post by Andrei Borzenkov
Post by Lennart Poettering
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.
How exactly is udev relevant here? This discussion has nothing to do
with udev.
systemd acts on udev's notifications. Other daemons do too. If you
don't want that all those apps and services act on it for your block
device, then the right approach is to block udev from doing so,
i.e. go to the source, not to the symptom.

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2018-01-24 19:12:40 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
1;5002;0c
Post by Andrei Borzenkov
Post by Lennart Poettering
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.
How exactly is udev relevant here? This discussion has nothing to do
with udev.
systemd acts on udev's notifications. Other daemons do too. If you
don't want that all those apps and services act on it for your block
device, then the right approach is to block udev from doing so,
i.e. go to the source, not to the symptom.
You cannot lock device that does not exist. And as soon as it appears it
is mounted.
Lennart Poettering
2018-01-24 19:54:26 UTC
Reply
Permalink
Raw Message
Post by Andrei Borzenkov
Post by Lennart Poettering
1;5002;0c
Post by Andrei Borzenkov
Post by Lennart Poettering
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.
How exactly is udev relevant here? This discussion has nothing to do
with udev.
systemd acts on udev's notifications. Other daemons do too. If you
don't want that all those apps and services act on it for your block
device, then the right approach is to block udev from doing so,
i.e. go to the source, not to the symptom.
You cannot lock device that does not exist. And as soon as it appears it
is mounted.
hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
to be a known path for a device, hence it must already be plugged in
already?

Also, it's not that systemd takes possession of arbitrary devices just
like that. It does that because the device was listed explicitly in
/etc/fstab as "auto" already, and your system wouldn't even have booted if
the device didn't show up during boot.

I think you have a different usecase though? Not sure I grok it
though? you want to turn off all hotplug handling for all future
devices entirely? what's the usecase?

Lennart
--
Lennart Poettering, Red Hat
Thomas Blume
2018-01-25 07:35:03 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Andrei Borzenkov
You cannot lock device that does not exist. And as soon as it appears it
is mounted.
hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
to be a known path for a device, hence it must already be plugged in
already?
Not necessarily, my aproach just reads a device name, given as parameter and
writes it somewhere.
The device doesn't have to exist therefore.
If the device name is wrong, just nothing would happen, so this seems to be
quite safe.

Using the flock approach makes systemd depending on util-linux.
I'm not sure whether this is ideal.

Regards
Thomas
Andrei Borzenkov
2018-01-27 10:23:50 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Andrei Borzenkov
Post by Lennart Poettering
1;5002;0c
Post by Andrei Borzenkov
Post by Lennart Poettering
Post by Thomas Blume
Would this be an acceptable approach?
Since a long time there has been a proper API for this: just take a
BSD file lock on the device node and udev won't bother with the
device anymore. As soon as you close the device fully (and thus also
lost all locks), udev will notice and then reprobe it again.
How exactly is udev relevant here? This discussion has nothing to do
with udev.
systemd acts on udev's notifications. Other daemons do too. If you
don't want that all those apps and services act on it for your block
device, then the right approach is to block udev from doing so,
i.e. go to the source, not to the symptom.
You cannot lock device that does not exist. And as soon as it appears it
is mounted.
hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
to be a known path for a device, hence it must already be plugged in
already?
Also, it's not that systemd takes possession of arbitrary devices just
like that. It does that because the device was listed explicitly in
/etc/fstab as "auto" already, and your system wouldn't even have booted if
the device didn't show up during boot.
a) If device has "nofail" systemd *will* boot without this device.
b) User is free to unmount and unplug this device even if it was present
in /etc/fstab. And when device is plugged again user may want to change
its content - repartition, reformat, whatever.
Post by Lennart Poettering
I think you have a different usecase though? Not sure I grok it
though? you want to turn off all hotplug handling for all future
devices entirely? what's the usecase?
Lennart
Michael Chapman
2018-01-25 20:05:49 UTC
Reply
Permalink
Raw Message
On Thu, 25 Jan 2018, Thomas Blume wrote:
[...]
Post by Thomas Blume
Suppressing the auto mount when a device (re)appears, is usually desired
during some administrative tasks.
What about lowering the hurdle for administrators by introducing a new
systemctl command?
systemctl lock $DEVICE
We could write the name of $DEVICE in some directory below /run/systemd.
An udev rule could parse this directory when an add event for a device
occurres and if $DEVICE matches, it could set SYSTEMD_READY=0.
systemctl unlock $DEVICE
That shouldn't be too hard to code either.
Would this be an acceptable approach?
You could just use:

systemctl --runtime mask path-to-mountpoint.mount

Or even:

systemctl --runtime mask /path/to/mountpoint

if systemd already has the mount unit loaded. That should prevent the
mount unit from being started -- i.e. prevent systemd from mounting the
filesystem.

The --runtime option ensures that the mask will go away upon the next
reboot, even if the admin forgets to call "systemctl --runtime unmask".
Lennart Poettering
2018-01-24 15:33:59 UTC
Reply
Permalink
Raw Message
Post by Franck Bui
Hi,
I'm resurrecting an old but recurrent issue here which I'd like to
clarify one more time.
Basically, systemd mounts all filesystems listed in /etc/fstab (unless
"noauto" is used) which is good since that's how fstab was used when
SysV was the init system.
However it also introduced another "feature" which basically
automagically mounts a filesystem (listed in fstab) every time its
backend device re-appears.
And this part confuses a lot of users since fstab has always been used
to list filesystems that should be mounted during the boot process
only. It has never been the place used by disk managers to list
mount-points that should be automatically mounted after the system
booted.
Well, the way I understood "auto" as opposed to "noauto" was "make
sure this is mounted while the system is up"...

I think it's moot discussing which intrepretation is the more correct
there, though…
Post by Franck Bui
Furthermore, it complicates the disk administrative tasks because now
one needs to be careful when it creates and initialize partitions
because systemd can mount the partition on the back of the user. We
recently had one such bug report (again).
You have to be careful there anyway. If you want exclusive access to a
block device, and don't want udev (and thus ultimately systemd) take
notice while you do that then take a BSD file lock on the device (see
other mail). Note that systemd is just one consumer of udev's
notifications there, and if you want to block all of them out while
you manipulate your block device, then there's no way around taking
the BSD lock anyway...
Post by Franck Bui
"mount it if it is around at boot, but not later" is not
available, since the idea is not compatible with modern
storage.
I'm not sure why the old behavior is not compatible with modern
static bool mount_is_auto(const MountParameters *p) {
assert(p);
- return !fstab_test_option(p->options, "noauto\0");
+ return fstab_test_option(p->options, "auto\0");
}
it seems to me that it could have the best of both worlds.
Well, traditionally "auto" was a boolean (and it is in the /bin/mount
sources still): "auto" means on, "noauto" means off. And the default
was "auto". Redefining this to make something else the default, or
even treating this as a tri-state now of "on", "off",
"something-in-between" sounds like a bigger redefinition than the
change systemd made there...
Post by Franck Bui
So the question is now: "what am I missing ?"
I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already). If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...

Lennart
--
Lennart Poettering, Red Hat
Franck Bui
2018-01-25 08:11:19 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Franck Bui
Furthermore, it complicates the disk administrative tasks because now
one needs to be careful when it creates and initialize partitions
because systemd can mount the partition on the back of the user. We
recently had one such bug report (again).
You have to be careful there anyway. If you want exclusive access to a
block device, and don't want udev (and thus ultimately systemd) take
notice while you do that then take a BSD file lock on the device (see
other mail).
It's not about udev here but it's about systemd which does a high-level
operation on the back of partition management tools (in fact some of
those tools may rely on udev's notifications)

We could suggest another workaround by masking the mount units before
operating on the block device. But it's still a workaround IMHO.

Indeed I can't see any useful use cases for this functionality
implemented by systemd and I'm really not sure there are users out there
who find it useful.

So why was it introduced in the first place ?
Post by Lennart Poettering
Note that systemd is just one consumer of udev's
notifications there, and if you want to block all of them out while
you manipulate your block device, then there's no way around taking
the BSD lock anyway...
Again I don't see why PID1 would need to implement such feature.
Post by Lennart Poettering
Well, traditionally "auto" was a boolean (and it is in the /bin/mount
sources still): "auto" means on, "noauto" means off. And the default
was "auto". Redefining this to make something else the default, or
even treating this as a tri-state now of "on", "off",
"something-in-between" sounds like a bigger redefinition than the
change systemd made there...
I disagree here.

Initially "noauto" is interpreted only (?) by "mount -a" which was done
during boot and can still be re-played later by admin. But in the later
case the command is *initiated* by him so there's no magic here.

systemd redefined this though: "auto" is equivalent to "run 'mount -a'
automatically when a backend device appears on udev's radar" which is
totally different. And it's the default: if neither "noauto" nor "auto"
is specified then the redefined "auto" is assumed.

The proposed change keeps the old default behavior: if neither "auto"
nor "noauto" is specified, do the equivalent of "mount -a" during boot only.

If "auto" is explicitly specified then keep the behavior introduced by
systemd too minimize the incompatible changes.

But honestly I would be in favor to remove it completely, see below.
Post by Lennart Poettering
Post by Franck Bui
So the question is now: "what am I missing ?"
I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already).
And we get regularly complains about this behavior.
Post by Lennart Poettering
If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...
We're taking about filesystems listed in fstab.

In my understanding fstab is not the placed to declare filesystems that
should be automagically mounted by apps. It should be mostly used by
"mount -a" during the boot process or when the command is issued by admins.

Actually I would tend to think that apps should leave alone any
filesystems in fstab, which usually lists filesystems used to setup the
system.

And systemd offers already another and better way to automatically
mounts filesystem when their target directory is accessed with automount
units.

So my best option would be to remove completely the redefinition of
"auto" option we have currently and would make it behaves like it did in
the past. If this "automagic" behavior appears to have some useful cases
then implement it via a totally different option supported by mount unit
(only) so there's no confusion anymore.

Thanks.
Colin Guthrie
2018-01-25 13:27:43 UTC
Reply
Permalink
Raw Message
Post by Franck Bui
Post by Lennart Poettering
Well, traditionally "auto" was a boolean (and it is in the /bin/mount
sources still): "auto" means on, "noauto" means off. And the default
was "auto". Redefining this to make something else the default, or
even treating this as a tri-state now of "on", "off",
"something-in-between" sounds like a bigger redefinition than the
change systemd made there...
I disagree here.
Initially "noauto" is interpreted only (?) by "mount -a" which was done
during boot and can still be re-played later by admin. But in the later
case the command is *initiated* by him so there's no magic here.
systemd redefined this though: "auto" is equivalent to "run 'mount -a'
automatically when a backend device appears on udev's radar" which is
totally different. And it's the default: if neither "noauto" nor "auto"
is specified then the redefined "auto" is assumed.
The proposed change keeps the old default behavior: if neither "auto"
nor "noauto" is specified, do the equivalent of "mount -a" during boot only.
If "auto" is explicitly specified then keep the behavior introduced by
systemd too minimize the incompatible changes.
But honestly I would be in favor to remove it completely, see below.
Isn't the whole "mount -a during boot" a fundamentally fuzzy concept? I
mean, "in the past" this only worked because there were artificial
delays introduced to make sure all devices were probably available
before trying to mount them.

As systemd is more reactive (i.e. hotplug friendly) what's to say a
device plugged in 2s after boot is not a device plugging in at boot but
which takes a while to appear on the bus and filter through to become a
device node?

I don't think it would make technical sense to define a period in time
which flips systemd over to behaving differently. That would be very
confusing and hard to define and convey to users. At least the current
way is consistent even if it does have some other issues to contend with.

Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Franck Bui
2018-01-25 14:40:55 UTC
Reply
Permalink
Raw Message
Post by Colin Guthrie
Post by Franck Bui
Initially "noauto" is interpreted only (?) by "mount -a" which was done
during boot and can still be re-played later by admin. But in the later
case the command is *initiated* by him so there's no magic here.
systemd redefined this though: "auto" is equivalent to "run 'mount -a'
automatically when a backend device appears on udev's radar" which is
totally different. And it's the default: if neither "noauto" nor "auto"
is specified then the redefined "auto" is assumed.
The proposed change keeps the old default behavior: if neither "auto"
nor "noauto" is specified, do the equivalent of "mount -a" during boot only.
[...]
Post by Colin Guthrie
Isn't the whole "mount -a during boot" a fundamentally fuzzy concept? I
mean, "in the past" this only worked because there were artificial
delays introduced to make sure all devices were probably available
before trying to mount them.
Sorry I was probably not clear: by "do the equivalent of "mount -a"
during boot only" I meant to mount fs listed in fstab (without
"noauto") the way it's done currently by systemd during boot.

During boot there shouldn't be any changes. The behavior change happens
later if neither "auto" nor "noauto" is specified: by default do not try
to automagically mount filesystems.
Uoti Urpala
2018-01-25 17:33:05 UTC
Reply
Permalink
Raw Message
Post by Franck Bui
Sorry I was probably not clear: by "do the equivalent of "mount -a"
during boot only" I meant to mount fs listed in fstab (without
"noauto") the way it's done currently by systemd during boot.
During boot there shouldn't be any changes. The behavior change happens
later if neither "auto" nor "noauto" is specified: by default do not try
to automagically mount filesystems.
This would require distinguishing "boot" and "non-boot" modes of
operation, so that systemd could switch mount handling behavior at some
point. How would you define where "boot" ends? You could try a
definition like "boot is over if there is no unit that is scheduled for
start and has been since the initial transaction", but then if you have
some obscure service that takes 5 hours to start, this could still lead
to very surprising sudden behavior changes on a system that has
otherwise been running for hours...

And if you define boot based on when some software has completed
starting, and have any mounts which are not necessary for boot to
succeed, then there's an obvious race condition - sometimes the devices
would become visible and be mounted during boot, sometimes the boot
would complete first and the devices would not be mounted
automatically. I doubt that would be what you'd want. I think this
issue makes your "only during boot" goal a bad idea in general for such
non-essential mounts.

For mounts that are required as part of the initial transaction, some
kind of "only mount this automatically if it has not been mounted
before" logic (rather than based on "is it boot" directly) is the
closest I can think of to a sane feature. But still not something that
I'd consider a particularly good idea.
Franck Bui
2018-01-26 09:30:31 UTC
Reply
Permalink
Raw Message
Post by Uoti Urpala
This would require distinguishing "boot" and "non-boot" modes of
operation, so that systemd could switch mount handling behavior at some
point. How would you define where "boot" ends?
Well "during boot" means mount units pulled in by local-fs.target unit.

Once pulled in by the initial transaction, a mount unit can either:

1. succeed if the device is already there and mount(8) succeeds
2. wait for the device appears or a timeout expire
3. enter in failed state if the timeout expires

This is the defaults and would match the behavior of SysV when it .

The concern here is that PID1 added a new behavior on top of that:

4. Each time the mount unit is inactive and the device shows up
automatically start the unit.

And indeed, if the device takes 5 hours to start, this "new" behavior
allows PID1 to mount asynchronously the device regardless of what
happened previously (assuming "nofail" option is used). But at first
glance disabling the timeout seems more appropriate...

Also how apps/users are supposed to access such devices ? should they
wait for systemd to signal that the mount unit is up ? isn't automount
more appropriate in this case ?

Even if some users might find it useful, redefining the meaning of
"auto" option doesn't look correct because as already explained a lot of
users dont expect it and it confuses some applications too.

IMHO introducing it with a brand new option would have been better and
much less confusing. Also this option shouldn't have been specific to
fstab but should have been part of the mount unit option set.

Thanks.
Franck Bui
2018-01-31 09:15:24 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already). If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...
Lennart, would you accept such changes ?

1. introduce a new option for mount units that turn ON/OFF
the automatic mount feature systemd introduced.

2. make fstab-generator uses this option if "noauto" is not
used. This would have the benefit to explicitly see if this
option is used when reading a mount unit file and make it
available for those who directly created mount units.

3. make a compile option (--compat-sysv-fstab or such) which
would turn the automatic mount feature OFF by default for
mount units generated by fstab-generator.

4. introduce a new kernel command line switch to override the
default (whatever its value).

5. introduce a new fstab option "x-systemd.auto" or such that
would override 3. and 4.

At least distros would be free to choose if they want to turn the
feature ON by default. And the adding of new options would clarify the
current situation IMHO.

Thanks.
Franck Bui
2018-02-12 14:55:06 UTC
Reply
Permalink
Raw Message
Post by Franck Bui
Post by Lennart Poettering
I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already). If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...
Lennart, would you accept such changes ?
ping
Post by Franck Bui
1. introduce a new option for mount units that turn ON/OFF
the automatic mount feature systemd introduced.
2. make fstab-generator uses this option if "noauto" is not
used. This would have the benefit to explicitly see if this
option is used when reading a mount unit file and make it
available for those who directly created mount units.
3. make a compile option (--compat-sysv-fstab or such) which
would turn the automatic mount feature OFF by default for
mount units generated by fstab-generator.
4. introduce a new kernel command line switch to override the
default (whatever its value).
5. introduce a new fstab option "x-systemd.auto" or such that
would override 3. and 4.
At least distros would be free to choose if they want to turn the
feature ON by default. And the adding of new options would clarify the
current situation IMHO.
Thanks.
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Loading...