Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Andreas Hasenack <andreas@canonical.com>
Date:   Fri, 8 Jul 2022 16:50:38 +0000
Message-ID: <CANYNYEFSdBua3Ay6jGk2cacossVJ8_CzDgDBnFCjXfk5XSoGEQ@mail.gmail.com>
Subject: Why keep var-lib-nfs-rpc_pipefs.mount around?
To:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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?
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