[systemd-devel] Should automount units for network filesystems be Before=local-fs.target?

[Felipe Sateler]

On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote:

> Hello all,
> 
> At present, when systemd-fstab-generator creates an automount unit for
> an fstab entry, it applies the dependencies that would have been put
> into the mount unit into the automount unit instead.
> 
> For a local filesystem, this automount unit would be
> Before=local-fs.target. For a network filesystem, it gets
> Before=remote-fs.target. If the mount is not noauto, it also gets a
> corresponding WantedBy= or RequiredBy= dependency.
> 
> Would it make more sense for the automount unit to be ordered before
> (and,
> if not noauto, be pulled in by) local-fs.target, even for network
> filesystems?
> 
> In a sense, the automount is a local filesystem, even though the thing
> that will eventually be mounted over the top of it isn't. Furthermore,
> this change would allow services that use automounted network filesystem
> to simply block until the filesystem has been mounted. Currently, for
> this to work correctly during boot, services need to be given explicit
> dependencies (e.g. After=remote-fs.target or RequiresMountsFor=...),
> since otherwise they may get started before the automount unit has
> started and thus be able to "see" the underlying filesystem.
> 
> I'm trying to work out what might break with such a change. I suppose it
> is possible somebody has two automounted network filesystems nested
> within one another... the second automount would be dependent upon the
> first being mounted, but that mount won't happen until the network is
> brought up, which is after local-fs.target. This doesn't seem like a
> particularly likely configuration though.
> 
> Is there any other reason this change wouldn't work?


I think the most likely failure point would be at shutdown:

1. foo.mount is unmounted, but foo.automount is still alive.
2. some.service is not Requires/After foo.mount
3. some.service tries to access /foo
4. systemd tries to activate foo.mount
5. boom

Since the whole point of the exercise was to have some.service start 
earlier, and this implies that some.service will be stopped later, I deem 
this scenario likely if what you propose were implemented.

-- 
Saludos,
Felipe Sateler