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

[Lennart Poettering]

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?

> Yeah, I don't really want to pull the whole .mount in early too, since I am
> relying on normal late-boot configuration of the network.
> 
> I'm going to have to just add After=remote-fs.target drop-ins for a whole
> _lot_ of services that could _possibly_ access data on network
> filesystems.

You can also add a drop-in to remote-fs.target and add a single line
listing the relevant services in the opposite direction.

> Unfortunately I don't really have control over what these services do, and I
> don't necessarily know which ones will actually need the network
> filesystems, so I'm going to just have to punt and add the drop-in on them
> all.
> 
> It's a pity that After=remote-fs.target isn't in a service's default
> dependencies (obviously, services that set up networking would then need
> DefaultDependencies=no, but there's far fewer of those). People generally
> expect most services to be started after mounting network filesystems, since
> pre-systemd Linux releases tended to do that. But it's too late to change
> the way default dependencies work now.

THere are some exceptions: systemd-user-sessions.service does order
itself after remote-fs.target, which means that anything involved with
human user logins will run with the mounts applied. Also, if you have
/var or /var/tmp on the network we'll pull that in explicitly in early
boot, as we don't support that being mounted in late boot.

On SysV where NM was used for network management, the only way you
could get network mounts established before your service is by
ordering your service after NM too.. It's not too different now,
except that instead of ordering yourself explicitly after NM we ask
you to order yourself after the more specific "remote-fs.target".

I would recommend packagers and downstreams for software that is
frequently used with data located on NFS shares to come with
RequiresMountsFor= for the relevant directories. For example, I think
stuff like MySQL would be good to ship with
RequiresMountsFor=/var/lib/mysql, just to make it nicer for those who
want to place that dir on NFS.

Lennart

-- 
Lennart Poettering, Red Hat