Re: [systemd-devel] Suppressing automounting

[Lennart Poettering]

On Fri, 12.09.14 15:25, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > From: Tobias Geerinckx-Rice 
> 
> > Step back, and define exactly what it is you actually need^Wwant to do.
> 
> For a certain entry in /etc/fstab (which will in practice always have
> the option "nofail"), if the device is not available "until booting is
> over" (which I'm willing to denote with a specified period of time),
> after that, it will not be automatically mounted if it becomes
> available.

This is currently not available, and it sounds very special and racy
to support it upstream I think. Sorry!

If you want to hack something up like this, I'd recommend writing a
timer unit/cronjob that creates a file $PATH after $SECONDS after boot. Then, 
add
a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and
write into it:

[Unit]
ConditionFileExists=!/the/file/you/create

That way the mount unit will always be queued, but will actually be
conditionalized out $SECONDS after boot, if you follow what I mean.

Hope this is helpful.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Tobias Geerinckx-Rice 

> That's not to say that it didn't happen to work most of the time. I
> just hoped systemd could do better. I still do.

I agree that systemd's current default behavior is better than the
previous default.  But there are some cases where I can easily define
behavior that would be much better (for me) than systemd's current
default behavior.  And indeed, better than the previous default
behavior.

What I am looking for is advice or pointers as to what a proper way to
implement a configurable option (presumably in /etc/fstab) that would
cause the behavior I want.

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

Re: [systemd-devel] Suppressing automounting

[Tobias Geerinckx-Rice]

Hallo,

On 14 September 2014 19:49, Andrei Borzenkov  wrote:
> В Thu, 11 Sep 2014 21:53:27 +0200
> Tobias Geerinckx-Rice  пишет:
>>
>> From my reading of the thread, this is to emulate as closely ye olde
>> initscripts' unreliable and flawed behaviour of attempting to mount
>> one or more devices exactly once (i.e., a one-shot "mount -a"), but
>> not until an arbitrary time-out has elapsed after which all external
>> devices are blindly assumed to have been initialised for no good
>> reason.
>
> This thread is not about "blindly assuming" anything.

Indeed it isn't. But the traditional application of fstab was. Badly [1].

That's not to say that it didn't happen to work most of the time. I
just hoped systemd could do better. I still do.

> Actually, it is systemd which blindly assumes user wants to
> always mount device as soon at it appears.

The device is in fstab, marked 'auto'. I submit that's closer to a
reasonable assumption than a blind one -- however...

>> This isn't hard to achieve with systemd,
>
> In case you missed it - it is impossible to achieve with systemd right
> now. At least, it is impossible to achieve what the goal of OP was -
> attempt to automount device exactly once on system boot and give up if
> it was not successful.

...yeah. Sorry. Quick story: for some unholy reason, the vintage Arch
VM I last used to test this always did the Right Thing:

  - Add a nofail fstab line, boot with the device present.
  - Verify that it was 'auto'-mounted. umount and (physically) unplug it.
  - Plug it back in. The device has the same path and active unit.
  - Yet nothing is mounted. All is well, if you like it that way.

Now, of course, that VM is gone. And now, with exactly the same
(logged) commands, the device is indeed silently mounted. Every time.
Even with old systemd.

Grr.

Now: is always mounting better than the old behaviour? -- Still think so.
Is it different from how everyone historically expects fstab to work,
and therefore confusing as hell until either properly documented or
(meh) made configurable? -- Hell yes.

Regardless: sorry for any noise!

T G-R

[1]: Lennart's remark, 'a concept of "mount at boot if it is there,
otherwise don't"
cannot work' 
,
isn't theoretical: it regularly broke on some dodgy hardware I'm
thankful to no longer own.

To paraphrase the OP: It never *really* worked. I don't want it back.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Andrei Borzenkov 

> At least, it is impossible to achieve what the goal of OP was -
> attempt to automount device exactly once on system boot and give up if
> it was not successful. Which had been semantic of /etc/fstab for quite
> some time.

I don't have a need to "automount device exactly once", only that
after a certain period of time, systemd would cease trying to mount
the device.

I'm guessing that a reasonable place to specify this would be in a
special option in the /etc/fstab line.

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

Re: [systemd-devel] Suppressing automounting

[Andrei Borzenkov]

В Thu, 11 Sep 2014 21:53:27 +0200
Tobias Geerinckx-Rice  пишет:

> 
> Step back, and define exactly what it is you actually need^Wwant to do.
> 

It was described clear enough already.

> From my reading of the thread, this is to emulate as closely ye olde
> initscripts' unreliable and flawed behaviour of attempting to mount
> one or more devices exactly once (i.e., a one-shot "mount -a"), but
> not until an arbitrary time-out has elapsed after which all external
> devices are blindly assumed to have been initialised for no good
> reason.
> 

This thread is not about "blindly assuming" anything. Actually, it is
systemd which blindly assumes user wants to always mount device as soon
at it appears.

> This isn't hard to achieve with systemd,

In case you missed it - it is impossible to achieve with systemd right
now. At least, it is impossible to achieve what the goal of OP was -
attempt to automount device exactly once on system boot and give up if
it was not successful. Which had been semantic of /etc/fstab for quite
some time.

> but there's a good reason I
> wrote it in such a silly manner, that can't simply be ignored.
> 
> Regards (and good luck nonetheless),
> 
> T G-R
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

Re: [systemd-devel] Suppressing automounting

[Andrei Borzenkov]

В Thu, 11 Sep 2014 13:41:25 -0400
wor...@alum.mit.edu (Dale R. Worley) пишет:

> > From: Colin Guthrie 
> 
> > I'm maybe missing something, but in the case of mount units, isn't that
> > framework program mount(8)?
> > 
> > It has a mechanism for parsing default options that apply to all mounts
> > and then calling out to the appropriate, filesystem specific mount
> > program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
> > if appropriate.
> 
> mount does the real work, of course, but it isn't the complete
> solution, because *something* has to figure out not only that
> /bin/mount should be invoked, but what its arguments are.

This is done by systemd binary just like for any other unit type. It
spawns /bin/mount to perform actual mount.
 
>   And as you
> can see from the unit file
> 
> # Automatically generated by systemd-fstab-generator
> 
> [Unit]
> SourcePath=/etc/fstab
> DefaultDependencies=no
> After=local-fs-pre.target
> Conflicts=umount.target
> Before=umount.target
> 
> [Mount]
> What=/dev/Freeze02/Store2
> Where=/Store
> Type=ext4
> FsckPassNo=0
> Options=nofail,x-systemd.device-timeout=1m,defaults
> 
> none of that is specified *directly* in the unit file.  Some piece of
> code has to know to assemble the What, Where, Type, and Options values
> (at the very least) -- and that piece of code is what contains special
> knowledge of how to handle mount units.
> 
> Dale
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

Re: [systemd-devel] Suppressing automounting

[Andrei Borzenkov]

В Thu, 4 Sep 2014 18:32:20 -0400
wor...@alum.mit.edu (Dale R. Worley) пишет:

> > From: Andrei Borzenkov 
> 
> > bor@opensuse:~/src/systemd> systemctl show boot.mount  -p WantedBy 
> > --no-pager
> > WantedBy=dev-sda1.device
> > 
> > Which has the effect that if device was not present at boot but appears
> > later, the very appearance of device triggers start of mount unit -
> > filesystem gets mounted.
> > 
> > And yes, this makes semantic very different from
> > traditional /etc/fstab. And I'm not sure it has to do it by default ...
> > honestly, I'm not sure it has to do it at all. I think about situation
> > where I have persistent device names (SAN, iSCSI, LVM) and need to do
> > maintenance which causes device nodes disappear and appear again. I
> > definitely do not want any filesystem to be suddenly mounted in this
> > case until I have finished my tasks.
> > 
> > And of course it is not documented anywhere.
> 
> I admit that I haven't studied systemd enough to understand the
> significance of WantedBy.  My understanding is that systemd performs a
> series of units, with dependencies showing which units must finish
> before other units start.

There are several types of dependencies; ordering is just one of them.
Please see "man systemd.unit" for full list. In this case WantedBy
means that when dev-sda1.device is started, systemd automatically
starts boot.mount. For a device unit "started" means systemd was
notified by udev that device had appeared (a bit simplified).

>   But it appears that boot.mount does not
> represent a particular task, but some sort of generic task that is
> executed multiple times, one for each ".device" unit. -- Or is "boot"
> the name of the mountpoint, and "boot.mount" only represents the work
> for mounting /dev/sd1 as /boot?
> 

Correct. boot.mount represents /boot mountpoint which in my case
resides on /dev/sda1. So above dependency means that when /dev/sda1
appears systemd tries to start boot.mount; and starting mount unit
means mounting it ...

> However, if I wanted to add an option that means "give up on
> attempting to mount this device after xx seconds", what would be a
> good way to organize it, given the architecture of systemd?

And once again - systemd *does* give up after xx seconds once it
initiated start of mount unit. Even without any explicit option (90
seconds is default timeout).

> It
> appears that there is a general mechanism for inserting information
> for systemd into the "options" part of an /etc/fstab line, so
> presumably the indication for the option would be placed there.
> 
> In my "Store.mount" file, I see no indication of an executable which
> implements the unit.  What is the code which implements it?

systemd binary, like any other unit. Code is in git on fdo.

> Would it
> be possible for that code to determine how long it has been?
> 

You have too many "it"s in this sentence; could you rephrase? But
systemd already has default timeout for any unit. You are looking in
the wrong place.

> Dale

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

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Tobias Geerinckx-Rice 

> Step back, and define exactly what it is you actually need^Wwant to do.

For a certain entry in /etc/fstab (which will in practice always have
the option "nofail"), if the device is not available "until booting is
over" (which I'm willing to denote with a specified period of time),
after that, it will not be automatically mounted if it becomes
available.

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

Re: [systemd-devel] Suppressing automounting

[Tobias Geerinckx-Rice]

Hallo,

On 11 September 2014 19:41, Dale R. Worley  wrote:
> > From: Colin Guthrie 
> > I'm maybe missing something, but in the case of mount units, isn't that
> > framework program mount(8)?
> >
> > It has a mechanism for parsing default options that apply to all mounts
> > and then calling out to the appropriate, filesystem specific mount
> > program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
> > if appropriate.
>
> mount does the real work, of course, but it isn't the complete
> solution,

Er, "solution" to what, exactly? People here seem (rightly)
unconvinced there's any problem at all.

And yes, calling mount -- by definition -- actually is the "complete
solution" to mounting a file system under Linux.

> because *something* has to figure out not only that
> /bin/mount should be invoked, but what its arguments are.
>
> And as you can see from the unit file
>
[SNIP]
> What=/dev/Freeze02/Store2
> Where=/Store
> Type=ext4
[SNIP]
> Options=nofail,x-systemd.device-timeout=1m,defaults
>
> none of that is specified *directly* in the unit file.

Now surely, calling

/usr/bin/mount $What $Where [-t $Type] [-o $Options]

is about as direct as it gets. Being able to substitute the only
constant in that equation with /usr/bin/gimp really isn't going to
solve any problem, real or imagined.

> Some piece of code has to know to assemble the What, Where, Type,
> and Options values (at the very least) -- and that piece of code is what
> contains special knowledge of how to handle mount units.

Again: straightforward use of a standard Unix API that just happens to
be in a separate binary != special knowledge. Really. It's
programming.

Step back, and define exactly what it is you actually need^Wwant to do.

>From my reading of the thread, this is to emulate as closely ye olde
initscripts' unreliable and flawed behaviour of attempting to mount
one or more devices exactly once (i.e., a one-shot "mount -a"), but
not until an arbitrary time-out has elapsed after which all external
devices are blindly assumed to have been initialised for no good
reason.

This isn't hard to achieve with systemd, but there's a good reason I
wrote it in such a silly manner, that can't simply be ignored.

Regards (and good luck nonetheless),

T G-R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Colin Guthrie 

> I'm maybe missing something, but in the case of mount units, isn't that
> framework program mount(8)?
> 
> It has a mechanism for parsing default options that apply to all mounts
> and then calling out to the appropriate, filesystem specific mount
> program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
> if appropriate.

mount does the real work, of course, but it isn't the complete
solution, because *something* has to figure out not only that
/bin/mount should be invoked, but what its arguments are.  And as you
can see from the unit file

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
After=local-fs-pre.target
Conflicts=umount.target
Before=umount.target

[Mount]
What=/dev/Freeze02/Store2
Where=/Store
Type=ext4
FsckPassNo=0
Options=nofail,x-systemd.device-timeout=1m,defaults

none of that is specified *directly* in the unit file.  Some piece of
code has to know to assemble the What, Where, Type, and Options values
(at the very least) -- and that piece of code is what contains special
knowledge of how to handle mount units.

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

Re: [systemd-devel] Suppressing automounting

[Colin Guthrie]

Dale R. Worley wrote on 10/09/14 20:56:
>> From: Mantas Mikulėnas 
> 
>>> What I was thinking of is, what is the program that reads (directly or
>>> indirectly) the Store.mount file and from that decides exactly how to
>>> call mount(8), and when to call it?
>>
>> It's systemd itself (pid 1).
>>
>>> My guess was that the name of this program would be listed *in* the
>>> *.mount file, but that does not appear to be so.
>>
>> That would not make any sense: if the program wasn't running yet, how
>> could it possibly start itself in order to read the .mount file which
>> just tells it to start itself?
> 
> In many systems, there's a framework program that reads a lot of
> control files which describe the bits of work to be done.  The
> framework program figures out the sequencing and dependencies of the
> various bits of work, while there are separate programs that *execute*
> the bits of work.  And the names of the execution programs are not
> hard-coded within the framework program, they are specified in the
> control files.  That sort of structure makes the framework program
> simpler, and enforces a defined interface between the framework
> program and the execution programs.  It also makes it easy to add new
> execution programs without changing the framework program.

I'm maybe missing something, but in the case of mount units, isn't that
framework program mount(8)?

It has a mechanism for parsing default options that apply to all mounts
and then calling out to the appropriate, filesystem specific mount
program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.)
if appropriate.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
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
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Mantas Mikulėnas 

> > What I was thinking of is, what is the program that reads (directly or
> > indirectly) the Store.mount file and from that decides exactly how to
> > call mount(8), and when to call it?
> 
> It's systemd itself (pid 1).
> 
> > My guess was that the name of this program would be listed *in* the
> > *.mount file, but that does not appear to be so.
> 
> That would not make any sense: if the program wasn't running yet, how
> could it possibly start itself in order to read the .mount file which
> just tells it to start itself?

In many systems, there's a framework program that reads a lot of
control files which describe the bits of work to be done.  The
framework program figures out the sequencing and dependencies of the
various bits of work, while there are separate programs that *execute*
the bits of work.  And the names of the execution programs are not
hard-coded within the framework program, they are specified in the
control files.  That sort of structure makes the framework program
simpler, and enforces a defined interface between the framework
program and the execution programs.  It also makes it easy to add new
execution programs without changing the framework program.

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

Re: [systemd-devel] Suppressing automounting

[Mantas Mikulėnas]

On Mon, Sep 8, 2014 at 10:32 PM, Dale R. Worley  wrote:
>> From: Simon McVittie 
>
>> > In my "Store.mount" file, I see no indication of an executable which
>> > implements the unit.
>>
>> I think it's always mount(8), which has its own extension mechanism to
>> dispatch per-filesystem if necessary (e.g. mount.cifs).
>
> What I was thinking of is, what is the program that reads (directly or
> indirectly) the Store.mount file and from that decides exactly how to
> call mount(8), and when to call it?

It's systemd itself (pid 1).

> My guess was that the name of this program would be listed *in* the
> *.mount file, but that does not appear to be so.

That would not make any sense: if the program wasn't running yet, how
could it possibly start itself in order to read the .mount file which
just tells it to start itself?

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Simon McVittie 

> > In my "Store.mount" file, I see no indication of an executable which
> > implements the unit.
> 
> I think it's always mount(8), which has its own extension mechanism to
> dispatch per-filesystem if necessary (e.g. mount.cifs).

What I was thinking of is, what is the program that reads (directly or
indirectly) the Store.mount file and from that decides exactly how to
call mount(8), and when to call it?

My guess was that the name of this program would be listed *in* the
*.mount file, but that does not appear to be so.

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

Re: [systemd-devel] Suppressing automounting

[Simon McVittie]

On 04/09/14 23:32, Dale R. Worley wrote:
> I admit that I haven't studied systemd enough to understand the
> significance of WantedBy.  My understanding is that systemd performs a
> series of units, with dependencies showing which units must finish
> before other units start.

Sort of. It has a goal (usually graphical.target or multi-user.target),
and achieves that goal by starting everything that that goal Requires or
Wants, recursively. While trying to achieve that goal, it uses
Before/After dependencies to get the "A must finish startup before B can
start" sequence.

> Or is "boot"
> the name of the mountpoint, and "boot.mount" only represents the work
> for mounting /dev/sd1 as /boot?

This. The root filesystem is -.mount, a separate /var would be
var.mount, a separate /var/cache would be var-cache.mount and so on.

> In my "Store.mount" file, I see no indication of an executable which
> implements the unit.

I think it's always mount(8), which has its own extension mechanism to
dispatch per-filesystem if necessary (e.g. mount.cifs).

S

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

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Andrei Borzenkov 

> bor@opensuse:~/src/systemd> systemctl show boot.mount  -p WantedBy --no-pager
> WantedBy=dev-sda1.device
> 
> Which has the effect that if device was not present at boot but appears
> later, the very appearance of device triggers start of mount unit -
> filesystem gets mounted.
> 
> And yes, this makes semantic very different from
> traditional /etc/fstab. And I'm not sure it has to do it by default ...
> honestly, I'm not sure it has to do it at all. I think about situation
> where I have persistent device names (SAN, iSCSI, LVM) and need to do
> maintenance which causes device nodes disappear and appear again. I
> definitely do not want any filesystem to be suddenly mounted in this
> case until I have finished my tasks.
> 
> And of course it is not documented anywhere.

I admit that I haven't studied systemd enough to understand the
significance of WantedBy.  My understanding is that systemd performs a
series of units, with dependencies showing which units must finish
before other units start.  But it appears that boot.mount does not
represent a particular task, but some sort of generic task that is
executed multiple times, one for each ".device" unit. -- Or is "boot"
the name of the mountpoint, and "boot.mount" only represents the work
for mounting /dev/sd1 as /boot?

However, if I wanted to add an option that means "give up on
attempting to mount this device after xx seconds", what would be a
good way to organize it, given the architecture of systemd?  It
appears that there is a general mechanism for inserting information
for systemd into the "options" part of an /etc/fstab line, so
presumably the indication for the option would be placed there.

In my "Store.mount" file, I see no indication of an executable which
implements the unit.  What is the code which implements it?  Would it
be possible for that code to determine how long it has been?

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

Re: [systemd-devel] Suppressing automounting

[Andrei Borzenkov]

В Fri, 29 Aug 2014 14:59:05 -0400
wor...@alum.mit.edu (Dale R. Worley) пишет:

> > From: wor...@alum.mit.edu (Dale R. Worley)
> 
> >When reading /etc/fstab a few special mount options are
> >understood by systemd which influence how dependencies are
> >created for mount points from /etc/fstab. [...]  If
> >x-systemd.device-timeout= is specified it may be used to
> >configure how long systemd should wait for a device to show up
> >before giving up on an entry from /etc/fstab. Specify a time in
> >seconds or explicitly specify a unit as s, min, h, ms.
> > 
> > I haven't tried this yet, but it should suffice for my problem.
> 
> OK, that test failed:  systemd does *not* stop attempting to mount a
> partition after x-systemd.device-timeout has passed.
> 

You misunderstand what happens here. x-systemd.device-timeout sets
*job* timeout - i.e. how long systemd waits when requested to mount
filesystem ("systemctl start Store.mount" in this case).

But when creating mount unit systemd also silently adds dependency to
*device*:

bor@opensuse:~/src/systemd> systemctl show boot.mount  -p WantedBy --no-pager
WantedBy=dev-sda1.device

Which has the effect that if device was not present at boot but appears
later, the very appearance of device triggers start of mount unit -
filesystem gets mounted.

And yes, this makes semantic very different from
traditional /etc/fstab. And I'm not sure it has to do it by default ...
honestly, I'm not sure it has to do it at all. I think about situation
where I have persistent device names (SAN, iSCSI, LVM) and need to do
maintenance which causes device nodes disappear and appear again. I
definitely do not want any filesystem to be suddenly mounted in this
case until I have finished my tasks.

And of course it is not documented anywhere.

> Here's the line in /etc/fstab:
> 
> /dev/Freeze02/Store2  /Store ext4 
> nofail,x-systemd.device-timeout=1m,defaults 0 0
> 
> And here's /run/systemd/generator/Store.mount:
> 
> # Automatically generated by systemd-fstab-generator
> 
> [Unit]
> SourcePath=/etc/fstab
> DefaultDependencies=no
> After=local-fs-pre.target
> Conflicts=umount.target
> Before=umount.target
> 
> [Mount]
> What=/dev/Freeze02/Store2
> Where=/Store
> Type=ext4
> FsckPassNo=0
> Options=nofail,x-systemd.device-timeout=1m,defaults
> 

I expected timeout to go in generated unit actually, not in mount
options.

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

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: wor...@alum.mit.edu (Dale R. Worley)

>When reading /etc/fstab a few special mount options are
>understood by systemd which influence how dependencies are
>created for mount points from /etc/fstab. [...]  If
>x-systemd.device-timeout= is specified it may be used to
>configure how long systemd should wait for a device to show up
>before giving up on an entry from /etc/fstab. Specify a time in
>seconds or explicitly specify a unit as s, min, h, ms.
> 
> I haven't tried this yet, but it should suffice for my problem.

OK, that test failed:  systemd does *not* stop attempting to mount a
partition after x-systemd.device-timeout has passed.

Here's the line in /etc/fstab:

/dev/Freeze02/Store2/Store ext4 
nofail,x-systemd.device-timeout=1m,defaults 0 0

And here's /run/systemd/generator/Store.mount:

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
After=local-fs-pre.target
Conflicts=umount.target
Before=umount.target

[Mount]
What=/dev/Freeze02/Store2
Where=/Store
Type=ext4
FsckPassNo=0
Options=nofail,x-systemd.device-timeout=1m,defaults

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

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Andrei Borzenkov 

> > > Here's an interesting fact:  What systemd does (in this situation)
> > > isn't true automounting; rather it waits for the *first* time the
> > > device/volume becomes available, and then mounts it.  Any later
> > > attachments of the volume do not cause mounting (until the next
> > > reboot).
> 
> Well, that's how /etc/fstab always behaved, right? Anything in there is
> "automounted" just once, when system boots. Later you have to manually
> do it.

That's true, it's how it is expected to work.  But that's not how I
described the situation originally -- I called it "automounting" -- so
upon discovering that I was wrong, I had to correct the record.

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

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Mantas Mikulėnas 

> For fstab, the units are created by a 'generator'
> (systemd-fstab-generator), which writes them under /run/systemd/generator
> every time the configuration is reloaded.
> 
> I'm not at my PC right now so I cannot check, but I /do/ remember someone
> mentioning that if a fstab entry has the 'auto' option, then the generator
> also symlinks the corresponding .mount unit under .device.wants/
> (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to
> be triggered *every* time that device appears on the system.
> 
> That is, in addition to local-fs.target triggering foo.mount and waiting
> for bar.device one time only (as you describe), it makes bar.device itself
> trigger foo.mount every time as well.

Thanks for the information!

I finally thought to do "man -k fstab" to see if it turned up
anything, and I found the manual page for "systemd-fstab-generator",
which references "systemd.mount", which tells me that I'm not the
first person with this complaint:

   When reading /etc/fstab a few special mount options are
   understood by systemd which influence how dependencies are
   created for mount points from /etc/fstab. [...]  If
   x-systemd.device-timeout= is specified it may be used to
   configure how long systemd should wait for a device to show up
   before giving up on an entry from /etc/fstab. Specify a time in
   seconds or explicitly specify a unit as s, min, h, ms.

I haven't tried this yet, but it should suffice for my problem.

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

Re: [systemd-devel] Suppressing automounting

[Andrei Borzenkov]

В Thu, 28 Aug 2014 00:31:49 +0300
Mantas Mikulėnas  пишет:

> On Aug 27, 2014 10:03 PM, "Dale R. Worley"  wrote:
> >
> > > From: Thomas Suckow 
> > >
> > > >> From: Lennart Poettering 
> > > >
> > > >> Note that a concept of "mount at boot if it is there, otherwise
> don't"
> > > >> cannot work.
> > > >
> > > > It worked until a week or two ago.  I want it back.
> > > >
> > > > I'm sure you're right that in the abstract, it cannot be made to
> > > > work.  But that isn't the problem I'm facing.
> > >
> > > It seems that a workaround could be to not put the volume in fstab
> > > and add a unit to the startup that would mount it if present. If you
> > > wanted to mount it later, you could manually start the unit again.
> >
> > I'd rather adjust systemd and leave fstab stable than vice-versa.
> >
> > Here's an interesting fact:  What systemd does (in this situation)
> > isn't true automounting; rather it waits for the *first* time the
> > device/volume becomes available, and then mounts it.  Any later
> > attachments of the volume do not cause mounting (until the next
> > reboot).
> >

Well, that's how /etc/fstab always behaved, right? Anything in there is
"automounted" just once, when system boots. Later you have to manually
do it.

> > But at this point, I only need to investigate the issue.  The
> > documentation I've managed to find about systemd is rather abstract,
> > there's no map between specific bits of functionality and the files
> > that control them.
> >
> > My understanding is that everything systemd does is controlled by
> > "units".  In this case, entries in fstab cause the creation of units
> > based on a "template".  If you could point me to the template file in
> > question, it would probably point me to all of the things I need to
> > investigate.
> 
> For fstab, the units are created by a 'generator'
> (systemd-fstab-generator), which writes them under /run/systemd/generator
> every time the configuration is reloaded.
> 
> I'm not at my PC right now so I cannot check, but I /do/ remember someone
> mentioning that if a fstab entry has the 'auto' option, then the generator
> also symlinks the corresponding .mount unit under .device.wants/
> (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to
> be triggered *every* time that device appears on the system.
> 
> That is, in addition to local-fs.target triggering foo.mount and waiting
> for bar.device one time only (as you describe), it makes bar.device itself
> trigger foo.mount every time as well.
> 

Hmm ... I'm not sure where this dependency comes from, but yes, it is
there

Requires=systemd-fsck@dev-sda1.service -.mount
Wants=system.slice
RequiredBy=local-fs.target systemd-sysctl.service
WantedBy=dev-sda1.device
Before=local-fs.target systemd-sysctl.service umount.target
After=systemd-journald.socket dev-sda1.device systemd-fsck@dev-sda1.service 
local-fs-pre.target system.slice -.mount

This looks like one of those implicit dependencies that are not
documented anywhere ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Mantas Mikulėnas]

On Aug 27, 2014 10:03 PM, "Dale R. Worley"  wrote:
>
> > From: Thomas Suckow 
> >
> > >> From: Lennart Poettering 
> > >
> > >> Note that a concept of "mount at boot if it is there, otherwise
don't"
> > >> cannot work.
> > >
> > > It worked until a week or two ago.  I want it back.
> > >
> > > I'm sure you're right that in the abstract, it cannot be made to
> > > work.  But that isn't the problem I'm facing.
> >
> > It seems that a workaround could be to not put the volume in fstab
> > and add a unit to the startup that would mount it if present. If you
> > wanted to mount it later, you could manually start the unit again.
>
> I'd rather adjust systemd and leave fstab stable than vice-versa.
>
> Here's an interesting fact:  What systemd does (in this situation)
> isn't true automounting; rather it waits for the *first* time the
> device/volume becomes available, and then mounts it.  Any later
> attachments of the volume do not cause mounting (until the next
> reboot).
>
> But at this point, I only need to investigate the issue.  The
> documentation I've managed to find about systemd is rather abstract,
> there's no map between specific bits of functionality and the files
> that control them.
>
> My understanding is that everything systemd does is controlled by
> "units".  In this case, entries in fstab cause the creation of units
> based on a "template".  If you could point me to the template file in
> question, it would probably point me to all of the things I need to
> investigate.

For fstab, the units are created by a 'generator'
(systemd-fstab-generator), which writes them under /run/systemd/generator
every time the configuration is reloaded.

I'm not at my PC right now so I cannot check, but I /do/ remember someone
mentioning that if a fstab entry has the 'auto' option, then the generator
also symlinks the corresponding .mount unit under .device.wants/
(e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to
be triggered *every* time that device appears on the system.

That is, in addition to local-fs.target triggering foo.mount and waiting
for bar.device one time only (as you describe), it makes bar.device itself
trigger foo.mount every time as well.

-- 
Mantas Mikulėnas 
// sent from phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Thomas Suckow 
> 
> >> From: Lennart Poettering 
> >
> >> Note that a concept of "mount at boot if it is there, otherwise don't"
> >> cannot work.
> >
> > It worked until a week or two ago.  I want it back.
> >
> > I'm sure you're right that in the abstract, it cannot be made to
> > work.  But that isn't the problem I'm facing.
> 
> It seems that a workaround could be to not put the volume in fstab
> and add a unit to the startup that would mount it if present. If you
> wanted to mount it later, you could manually start the unit again.

I'd rather adjust systemd and leave fstab stable than vice-versa.

Here's an interesting fact:  What systemd does (in this situation)
isn't true automounting; rather it waits for the *first* time the
device/volume becomes available, and then mounts it.  Any later
attachments of the volume do not cause mounting (until the next
reboot).

But at this point, I only need to investigate the issue.  The
documentation I've managed to find about systemd is rather abstract,
there's no map between specific bits of functionality and the files
that control them.

My understanding is that everything systemd does is controlled by
"units".  In this case, entries in fstab cause the creation of units
based on a "template".  If you could point me to the template file in
question, it would probably point me to all of the things I need to
investigate.

Thanks,

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

Re: [systemd-devel] Suppressing automounting

[Thomas Suckow]

On 08/20/2014 06:46 AM, Dale R. Worley wrote:

From: Lennart Poettering 



Note that a concept of "mount at boot if it is there, otherwise don't"
cannot work.


It worked until a week or two ago.  I want it back.

I'm sure you're right that in the abstract, it cannot be made to
work.  But that isn't the problem I'm facing.



It seems that a workaround could be to not put the volume in fstab and add a 
unit to the startup that would mount it if present. If you wanted to mount it 
later, you could manually start the unit again.

Regards,
Thomas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing automounting

[Dale R. Worley]

> From: Lennart Poettering 

> Note that a concept of "mount at boot if it is there, otherwise don't"
> cannot work.

It worked until a week or two ago.  I want it back.

I'm sure you're right that in the abstract, it cannot be made to
work.  But that isn't the problem I'm facing.

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

Re: [systemd-devel] Suppressing automounting

[Lennart Poettering]

On Tue, 19.08.14 15:56, Dale R. Worley (wor...@alum.mit.edu) wrote:

> (This is more proper for a systemd-users mailing list, but I can't
> find one.)
> 
> I'd like to customize my systemd.  (I'm running Fedora Linux 19, with
> systemd-204-20.fc19.x86_64.)
> 
> I have a line in /etc/fstab like this, which refers to a logical
> volume on a USB storage device:
> 
> /dev/Freeze02/Store2  /Store2ext4 nofail,defaults 0 0
> 
> Of course, if the logical folume Store2 is present at boot time, it
> gets mounted.

This is not really what "nofail" means in a systemd context. It just
means that we won't delay the boot process for this device to show
up. This means that the device will be mounted as it shows up but we
won't wait for it at boot. 

To turn off automatic mounting of the device, you need to use "noauto"
instead.

Note that a concept of "mount at boot if it is there, otherwise don't"
cannot work. The problem here is that most modern storage devices can
take any time they want to initialize and we simply have no idea how
long to wait for them. Because of that we just wait for the file systems
listed in /etc/fstab and immediately continue.

Especially on USB there's no point in time known where all devices have
to have reported back to the OS, they can take any time they want. (For
the most extreme case, think of Android devices, which when plugged into
a PC actually require confirmation on the device before the device shows
up!)

> In the past, once the system is running, if I plug in the storage
> device, the volume does not get mounted unless I manuall issue "mount
> /Store2".
> 
> More recently, if I plug in the storage device, the volume gets
> mounted automatically.  Messages in /var/log/messages suggest that
> systemd is doing the mounting.

Correct.

> I would like to suppress the latter automatic mounting.  (This is for
> all filesystems, which means I don't want to have to modify every
> fstab line.)

Well, this is not possible with the current logic. You have three choices:

a) not mount it at all by default (noauto)
b) wait for it at boot and mount it (default)
c) don't wait for it, but mount it as it shows up (nofail)

As mentioned an option d) of "mount it if it is around at boot, but not
later" is not available, since the idea is not compatible with modern
storage.

> The documentation of systemd is voluminous and hard to understand, but
> I believe that in order to do this, I need to provide systemd with a
> value that applies to all *.automount units that suppresses the action
> of the unit.  Because I do not want to put "noauto" in the fstab line,
> I expect that the initial mounting will still be done if the logical
> volume is present at boot time.  I'm guessing that putting something
> in a "automount@.service" file will suffice.

The ".automount" units actually are about something slightly different:
they are a way how you can establish mount points without actually
backing them immediately with a file system, but simply delaying that
until the first access. They implement what autofs4 or amd do, too. It
is not directly related to what you are trying to do.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel