Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2019-04-30 Thread Franck Bui
On 4/30/19 11:44 AM, Michael Biebl wrote:
> Am Di., 30. Apr. 2019 um 11:20 Uhr schrieb Franck Bui :
>> Just in case, this "feature" has been finally removed since v242 (commit 
>> 42b8142d7).
> 
> I can't find a commit with that id
> https://github.com/systemd/systemd/commit/42b8142d7
> 

Sorry it's 142b8142d7bb84f07ac33fc00527a4d48ac8ef9f.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2019-04-30 Thread Michael Biebl
Am Di., 30. Apr. 2019 um 11:20 Uhr schrieb Franck Bui :
> Just in case, this "feature" has been finally removed since v242 (commit 
> 42b8142d7).

I can't find a commit with that id
https://github.com/systemd/systemd/commit/42b8142d7

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2019-04-30 Thread Franck Bui
On 1/23/18 3:47 PM, Franck Bui wrote:
> 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.
> 

Just in case, this "feature" has been finally removed since v242 (commit 
42b8142d7).

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-02-12 Thread Franck Bui
On 01/31/2018 10:15 AM, Franck Bui wrote:
> On 01/24/2018 04:33 PM, Lennart Poettering wrote:
>> 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

>  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
> 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] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-31 Thread Franck Bui
On 01/24/2018 04:33 PM, Lennart Poettering wrote:
> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-27 Thread Andrei Borzenkov
24.01.2018 22:54, Lennart Poettering пишет:
> On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> 24.01.2018 22:08, Lennart Poettering пишет:
>>> On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>>> 1;5002;0c
 24.01.2018 17:13, Lennart Poettering пишет:
> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:
>
>> 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.

> 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
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-26 Thread Franck Bui
On 01/25/2018 06:33 PM, Uoti Urpala wrote:
> 
> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-25 Thread Michael Chapman

On Thu, 25 Jan 2018, Thomas Blume wrote:
[...]

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?


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".

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-25 Thread Uoti Urpala
On Thu, 2018-01-25 at 15:40 +0100, Franck Bui wrote:
> 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.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-25 Thread Franck Bui
On 01/25/2018 02:27 PM, Colin Guthrie wrote:
>> 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.
>>

[...]

> 
> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-25 Thread Colin Guthrie
Franck Bui wrote on 25/01/18 08:11:
>> 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/


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-25 Thread Franck Bui
On 01/24/2018 04:33 PM, Lennart Poettering wrote:
>> 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 ?

> 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.
> 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.

>> 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.

> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Thomas Blume

On Wed, 24 Jan 2018, Lennart Poettering wrote:


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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Lennart Poettering
On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 24.01.2018 22:08, Lennart Poettering пишет:
> > On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> > 1;5002;0c
> >> 24.01.2018 17:13, Lennart Poettering пишет:
> >>> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:
> >>>
>  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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Andrei Borzenkov
24.01.2018 22:08, Lennart Poettering пишет:
> On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 1;5002;0c
>> 24.01.2018 17:13, Lennart Poettering пишет:
>>> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:
>>>
 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Lennart Poettering
On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:
1;5002;0c
> 24.01.2018 17:13, Lennart Poettering пишет:
> > On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:
> > 
> >> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Lennart Poettering
On Di, 23.01.18 15:47, Franck Bui (f...@suse.de) wrote:

> 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…

> 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...

> 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.

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...

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Lennart Poettering
On Di, 23.01.18 16:54, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 23.01.2018 um 16:49 schrieb Simon McVittie:
> > On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
> > > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Lennart Poettering
On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-24 Thread Thomas Blume

On Tue, 23 Jan 2018, Simon McVittie wrote:


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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread Reindl Harald



Am 23.01.2018 um 20:09 schrieb Mike Gilbert:

On Tue, Jan 23, 2018 at 10:54 AM, Reindl Harald  wrote:

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)

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

[root@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

[root@srv-rhsoft:~]$ cat /etc/fstab | grep /mnt/arrakis
sshfs#reindl@arrakis:/ /mnt/arrakis   fuse
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


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

[harry@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.0 +0100
Modify: 2017-12-21 15:07:12.0 +0100
Change: 2017-12-21 15:07:12.0 +0100
 Birth: -
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread Mike Gilbert
On Tue, Jan 23, 2018 at 10:54 AM, Reindl Harald  wrote:
>
>
> Am 23.01.2018 um 16:49 schrieb Simon McVittie:
>>
>> On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
>>>
>>> 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)
>
> [root@srv-rhsoft:~]$ systemctl daemon-reload
>
> [root@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
>
> [root@srv-rhsoft:~]$ cat /etc/fstab | grep /mnt/arrakis
> sshfs#reindl@arrakis:/ /mnt/arrakis   fuse
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread Reindl Harald



Am 23.01.2018 um 16:49 schrieb Simon McVittie:

On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:

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)


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

[root@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


[root@srv-rhsoft:~]$ cat /etc/fstab | grep /mnt/arrakis
sshfs#reindl@arrakis:/ 
/mnt/arrakis   fuse 
noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread Simon McVittie
On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
> 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.

> [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.

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread 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.

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel