[systemd-devel] fstab generator and nfs-client.target

[Lennart Poettering]

On Sun, 26.07.15 00:08, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> В Sat, 25 Jul 2015 12:50:39 +0200
> Michael Biebl <mbiebl at gmail.com> пишет:
> 
> > 2015-07-25 3:18 GMT+02:00 Rich Freeman <r-systemd at thefreemanclan.net>:
> > > I noticed that mount units for nfs shares created by the generator do
> > > not Want=nfs-client.target or similar.
> > >
> > > That means that if you don't explicitly want nfs-client in your
> > > configuration then nfs shares will get mounted, but services like
> > > rpc-statd-notify.service won't run.
> > >
> > > Would it make sense to have the generator add the nfs-client target as
> > > a want to nfs mount services it creates?
> > 
> > remote mount units do have a "After remote-fs-pre.target" ordering and
> > tools like nfs-common/rpcbind are supposed to hook up into
> > remote-fs-pre.target.
> > 
> 
> They are supposed to be /ordered before/ remote-fs-pre.target; but I do
> not remember that remote-fs-pre.target itself was intended to pull
> anything. This was designed as pure synchronization point.
> 
> > http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target
> > 
> 
> --><--
> Note that this unit is generally not part of the initial transaction,
> unless the unit that wants to be ordered before all remote mounts pulls
> it in via a Wants= type dependency.
> --><--
> 
> So if I read it, nfs-common should pull in remote-fs-pre, but that
> leaves question what should pull in nfs-common itself.

Remote mounts are ordered after network.target, after
remote-fs-pre.target and after network-online.target.

remote-fs-pre.target and network.target are indeed "passive", they
should be pulled in by the service that wants to be the hook, not by
the mount that uses it. r-f-p.t is specifically for network mounts in
this case, while n.t is more generic. r-f-p.t is much stricter
defined, while n.t is very loosely defined and mostly about shutdown
order, not so much abotu startup order.

n-o.t otoh is an "active" target, it's actively pulled in by all
remote mounts, and hence can be used to add a service to the
transaction as soon as a remote mount is attempted.

Coming back to your original question, there are two options: 

1) nfs-common becomes a normal multi-user.target service, but adds
   Before=remote-fs-pre.target. This way, the service is started at
   boot, and not only on first use.

2) nfs-common makes itself pulled in by network-online.target, and
   orders itself before that. This way, the service is started when
   the network is upped.

If you are looking for a way to start this service only when an NFS
mount is attempted, then I must disappoint you: there's currently no
way to do this nicely, as you can neither express "applies only to
NFS", nor is there a way to actively pull in things from remote
mounts.

(There's a reason for both limitations: we try to avoid pull-deps on
mounts, since we want to keep the effect of manually ordered
/bin/mount invocations, and systemd-ordered .mount activations as
close as possible.)

Hope this is useful,

Lennart

-- 
Lennart Poettering, Red Hat