[systemd-devel] Is there a way to override the "Where" option in mount units?

[Lennart Poettering]

On Mi, 01.11.17 22:15, NeilBrown (neilb at suse.com) wrote:

> > Hmm, rpc_pipefs is a virtual API fs, right? If so, it really shouldn't
> > be mounted below /var in the first place. Any chance you can work with
> > the NFS folks to maybe move it below /run (or /sys or so) where API
> > file systems really belong? Otherwise everybody who wants to run /var
> > on FNS will run into the same problems sooner or later.
> >
> > Neil, maybe you could comment on this? Thanks!
> 
> What good timing.. nfs-utils-2.2.1 was just released yesterday.
> It contains
>   http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=3892174834ea1a4729348f0ecd3078cc1d5458e4
> 
> If you have a file /etc/nfs.conf which contains
> 
> [general]
>  pipefs-directory = /run/nfs/rpc-pipefs
> 
> then a generator will create the required .mount unit, and all
> tools and daemons will know where to look for the filesystem.

Any chance this can be made the default? Otherwise everybody who wants
/var on NFS will first have to reconfigure things.

BTW, I quickly glanced over the patch you linked, and one thing I
noticed: you enumerate through /etc/mtab in the generator. However,
mtab is long obsolete, and should not be used anymore. In fact we
nowadays will "taint" systemd if we notice that /etc/mtab is not a
symlink to /proc/self/mounts. It's simply unsupported, and new code
really should not reference the concept anymore... (oh, and the
offical way to refernce mtab is through libc's _PATH_MOUNTED define
btw...)

Now, one step better than still using /etc/mtab is using
/proc/self/mounts, but that's kinda legacy too, the new thing du jour
is /proc/self/mountinfo now.

But then again, I'd suggest using statfs and comparing the magic. It's
so much simpler...

Lennart

-- 
Lennart Poettering, Red Hat