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

[Michael Chapman]

On Fri, 28 Apr 2017, Felipe Sateler wrote:
> 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

Well, the shutdown target is started irrevocably, so I suspect instead of 
"boom" the service will just block until it's stopped by systemd.

But yeah, you do raise a good issue.

This is all a bit annoying. I've got a bunch of services (across multiple 
servers), but I don't necessarily know up front which services will be 
requiring access to network filesystems. I would prefer not to have to 
configure them all with After=remote-fs.target "just in case". I was 
hoping that by using automounts this wouldn't be necessary, but the 
services can end up being started _before_ those automounts.

In a sense, this is a bit of a regression from sysv initscripts, because a 
lot of initscripts were shipped with "Required-Start: $remotefs" just as a 
precautionary measure, but most vendor-provided systemd units do _not_ 
have After=remote-fs.target.

So is there any other way I could achieve what I want, or am I forced to 
drop in After=remote-fs.target wherever it might possibly be necessary?