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

[Michael Chapman]

On Sun, 30 Apr 2017, Lennart Poettering wrote:
> On Sat, 29.04.17 22:04, Michael Chapman (mike at very.puzzling.org) wrote:
>
>>> We can't really do that in the generic case, sorry. The distinction
>>> between local-fs.target and remote-fs.target mostly exists because the
>>> latter may rely on network management services which aren't available
>>> in early boot. Spefically, NetworkManager traditionally runs during
>>> late boot, not during early boot. Now, if we'd permit that an autofs
>>> mount is already established in early boot but can only be fulfilled
>>> in late boot, then we'd open the doors to a variety of deadlocks
>>> triggered by early-boot services accessing these mounts at a point in
>>> time where the backing mounts cannot be established yet.
>>
>> That would imply these early boot services accessing paths that are going to
>> be over-mounted by the network filesystem later on... which is a tad
>> strange, but admittedly quite possible.
>
> Well, I assumed that your services are of this kind. Because if they
> aren't, and they do not access the autofs mounts, then you can simply
> mount them in late boot without ill effect. Am I missing something?

You were talking about early-boot services. The services I'm dealing with 
are perfectly ordinary late-boot services. The problem is that the network 
filesystem automounts are perfectly ordinary late-boot services too, so 
there's no implicit ordering there.... the services _sometimes_ (but not 
always!) start before the automounts, which means they sometimes see the 
directory underlying the mount point.

I thought that maybe having these automounts done earlier would solve this 
kind of problem in the general case, but I now understand the new problems 
that could arise with such a change.

Thanks for your help!