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?
Attachment:
signature.asc
Description: OpenPGP digital signature
