[systemd-devel] RequiresMountsFor and the noauto option.

[Andrei Borzenkov]

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

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.

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

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: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170123/c62dc378/attachment.sig>