My apologies delayed response... extended PTO
On 7/11/22 9:13 AM, Benjamin Coddington wrote:
On 8 Jul 2022, at 12:50, Andreas Hasenack wrote:
Hi,
I was tracking down a Debian/Ubuntu bug with nfs-utils 2.6.1 where in
one case, after installing the packages, you would end up with
rpc_pipefs mounted at the same time in two locations: /run/rpc_pipefs
and /var/lib/nfs/rpc_pipefs. The /run location is what debian/ubuntu
default to.
After poking around a bit, I think I found out why that is
happening[1], but it led me to ask this question: why is
var-lib-nfs-rpc_pipefs.mount (and its corresponding rpc_pipefs.target
unit) still shipped, given that nfs-utils now has a generator?
Could just be an oversight, or perhaps a better reason exists. The
nfs-utils userspace has to handle a lot of different cases and legacy
setups.
Steve D, do you know?
Its not clear to me, if the read from nfs.conf does not
happen how changing the rpc_pipefs directory could happen.
When the read from nfs.conf happens and the rpc_pipefs directory
is not defined, the compiled in default rpc_pipefs directory
will be used and the generator will exit and not
generating the systemd files (using the installed ones).
If the rpc_pipefs directory is defined in nfs.conf, the
generator will set up that directory as the
rpc_pipefs directory and systemd files will be
generated.
So by taking out the nfs.conf read, the only way to change
the default rpc_pipefs directory is to recompile nfs-utils.
steved.
Ben
Shouldn't the generator be enough for all cases, where rpc_pipefs is
mounted in the default compile-time location, or changed via a config
change to nfs.conf? I know currently it checks[2] whether the config
points at the default location, but that check could just be skipped
and then the generator would always produce the correct mount and
target units.
1.
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1971935/comments/22
2.
https://salsa.debian.org/kernel-team/nfs-utils/-/blob/master/systemd/rpc-pipefs-generator.c#L138
