[systemd-devel] [BUG] network filesystems are no longer ordered after network.target by default
lennart at poettering.net
Tue Nov 1 15:58:32 PDT 2011
On Mon, 17.10.11 17:59, Tom Gundersen (teg at jklm.no) wrote:
> Since commit 21e557edcc1894ce4eeb70b71ca16e82e95bc0df (units:
> introduce local-fs-pre.target and remote-fs-pre.target), network
> mounts are ordered after local-fs-pre.target rather than after
> network.target. This is fine if remote-fs-pre.target is enabled (as it
> is ordered after network.target), but by default remote-fs-pre.target
> is not pulled in.
Fixed in git now. git will order all remote mounts after both r-f-p.t
and n.t so that things should work fine.
> I'm not sure what the intention is, so I did not include a patch.
The intention was to provide the network storage with a nice way how can
they can start services between the time the network is started and the
time remote mounts are applied. This is necessary for some network file
systems which need local auxiliary daemons to work.
> However, I notice that the local version does not have an [Install]
> section, and is pulled in by default, whereas the remote version must
> be enabled manually. I guess it would be more intuitive if they
> behaved the same...
Yupp, I fixed that too now: the r-f-p.t has no longer a [Install]
section. It's intended to be pulled in by services which need it as a
hook but should never be enabled explicitly by the user.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel