[systemd-devel] RequiresMountsFor and the noauto option.

[NeilBrown]

On Mon, Jan 23 2017, Andrei Borzenkov wrote:

> This was discussed just recently as regression in Leap 42.2 on opensuse
> mailing list ...
>
> 23.01.2017 03:13, NeilBrown пишет:
>> 
>> hi,
>>  according to "man systemd.unit" :
>> 
>>        RequiresMountsFor=
>>            Takes a space-separated list of absolute paths.
>>            Automatically adds dependencies of type Requires= and
>>            After= for all mount units required to access the
>>            specified path.
>> 
>>            Mount points marked with noauto are not mounted
>>            automatically and will be ignored for the purposes of
>>            this option. If such a mount should be a requirement for
>>            this unit, direct dependencies on the mount units may be
>>            added (Requires= and After= or some other combination).
>> 
>> 
>>  I understand this to mean that if a mount point has the "noauto" option in
>>  /etc/fstab, and if a systemd service has RequiresMountsFor the path to
>>  that mount point, then the service will *not* require the mount point,
>>  and it will start even if that mountpoint cannot be mounted.
>> 
>>  I recently made a change to nfs-utils to make use of this
>>  functionality.  A generator creates RequiresMountsFor dependences for
>>  nfs-server so that it won't start until all exported filesystems
>>  (listed in /etc/exports) are mounted.  I assumed this would not trigger
>>  the mounting of filesystems marked as "noauto".  I really want After
>>  functionality, but not Requires.
>> 
>>  However, this is not how it works.
>> 
>>  The "noauto" option stops a "Requires" dependency being created for
>>  local-fs.target, but does not stop a "Requires" dependency being
>>  created for a service which "RequiresMountsFor".  There is no checking
>>  for "noauto" in unit_add_mount_dependencies().
>> 
>>  If this a bug in the documentation, or a bug in the code?  I'm hoping
>
> Well ... I do not see any special handling for noauto in original commit
> that added this option (7c8fa05c4d5d01748ff2a04edb882afb3119b7d7). Nor
> do I see even theoretical possibility to handle it, because "noauto"
> just means "mount unit is not dependency of local-fs.target".

I could Theoretically be handled by having any unit with declares
"RequiresMountsFor" getting either "Requires local-fs.target" or
"Requires remote-fs.target" instead of the current "Requires foo.mount",
depending on whether the "foo.mount" is a 'net'
filesystem.... presumably that can be measured.
The "After foo.mount" dependency would remain.

Maybe a bit clumsy, but I think it could "theoretically" be made to work"

>
> What I suspect happened was
>
> - original patch depends on mount unit being present in systemd cache
> - due to aggressive garbage collection mount units without "auto" were
> displaced from cache early. So those units were not visible at the time
> dependency was checked
> - later c7c89abb9edf9320246482bf4a8e0656199281ae made systemd to always
> (try to) load all possible mount units for prefix
>
> Long story short - this is documentation bug (added
> 5d2abc04fc95f5c5f6d0eaf2f9b06c70d504019f by mistake). This option always
> was designed to *Require* other mount unit.

I agree that the name "Requires" seemed to be inconsistent with the
behaviour described, but it seems more strange that the behaviour with
respect to "noauto" would be explicity described if it was not
intentional.

.... ah-ha.  The documentation was change by commit
Commit: 5d2abc04fc95 ("man: document relationship between RequiresMountsFor and noauto")

in response to https://bugzilla.redhat.com/show_bug.cgi?id=1088057

So it was really documenting behaviour, not intention. ????
I should systemd promised some sort of stable API thing.....


>
>>  the later, otherwise I'll need to find a different solution for
>>  nfs-utils, and that will probably require having my generator read
>>  /etc/fstab and duplicate the work of fstab-generator.c
>> 
>>  If the documentation is wrong, and the code is correct, would it be
>>  possible to get "AfterMountsFor=" as that is the functionality that I
>>  really want.
>> 
>
> That's rather interesting question. As discussed in the thread I
> mentioned, user has /foo/bar in /etc/exports. So the question now is -
> what is semantic if /foo/bar is not mounted? nfsd server starts and
> export /foo/bar *mount point*, right? But that feels just as wrong, does
> not it?

It depends.
If the directory being exported is a subdirectory of the mountpoint,
then there will be no directory to export and the client will see ESTALE
or ENOENT (depending on exact sequence of events).  This is correct.

/etc/exports has a 'mountpoint' option which causes an entry to be
ignored if it is not, in fact, a mountpoint.  This works well for NFSv3
but is a bit awkward for NFSv4 (I don't recall exactly why).
Setting "mountpoint" on exports of filesystems which are "noauto" will
avoid most of the strange behaviour that you fear.

I could change the nfs-server generator to only RequiresMountsFor export
points that do not have the "mountpoint" option.  I considered that at
the time, but didn't because the systemd documentation told me I didn't
need to. :-(

Back to the drawing-board I guess .... but I'd really like to see the
documentation for systemd.unit reverted before I commit a change to
nfs-utils.

Thanks,
NeilBrown


>
> I.e. if some unit refers to path /foo/bar and we *know* that /foo/bar is
> on filesystem /foo - should we skip mounting filesystem? Then we risk
> unit misbehavior, because it will miss some data in /foo/bar, right?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170123/23601828/attachment.sig>