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

[Lennart Poettering]

On Mon, 27.07.15 13:25, Rich Freeman (r-systemd at thefreemanclan.net) wrote:

> On Mon, Jul 27, 2015 at 10:51 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> >
> > 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.
> 
> Presumably if the .mount unit had Wants=nfs-common.target or something
> similar it would pull it in when it mounts, right?  That would
> probably require a change to the generator to detect nfs shares and
> add this.
> 
> Whether you want to do it that way is a different matter.

Yeah, we want to avoid such fs-specific hacks. 

Note that there's generic support via mount options for this via the
x-systemd.requires= fstab option. See systemd.mount(5) for
details. But that requires patching fstab of course.

> > (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.)
> 
> Would it actually affect ordering?
> 
> If the mount wants nfs-common and is after remote-fs-pre.target, and
> nfs-common is before remote-fs-pre.target is after nfs-common, then
> won't nfs-common be started before any remote fs are mounted?  The
> only change would be that the mount wants nfs-common, so that it is
> started when it otherwise might not have been.
> 
> Or am I missing something?

What I tried to say is that we don't want to add too many implicit
requirement deps to mounts, but only ordering deps, so that carefully
paced manual /bin/mount invocations have pretty much the same effect
as those done by systemd itself: the number of units pulled in should
be the same. It's basically the same reason we never added
ExecStartPre= or so to .mount units: the effect of "/bin/mount /foo"
invocations should be similar to what systemd would do due to
"systemctl start /foo", modulo the ordering. The executed commands
should be the same. (Of course, if you use x-systemd.requires= as
suggested above, or if you write manual .mount files, then the effect
will be quite different, but then you did this explicitly, and
hopefully knowingly, and that's OK. However we should be careful with
too many automatisms there...)

I hope that makes some sense,

Lennart

-- 
Lennart Poettering, Red Hat