Re: Why keep var-lib-nfs-rpc_pipefs.mount around?

[Andreas Hasenack <andreas@canonical.com>]

Hi,

On Sat, Jul 23, 2022 at 2:29 PM Steve Dickson <steved@redhat.com> wrote:
>
> 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.

The read happens, it's just that in that particular bug scenario, the
/etc/nfs.conf file isn't there yet.

In the debian case, two things are triggering this bug[1]:
- the /etc/nfs.conf file is not shipped by the package in that
location. Instead, it's put in place by the postinst script (like
rpm's %postinst)[2].
- autofs recommends[3], not depends, nfs-common. This means that
autofs can be setup before nfs-common is, and if that happens,
/etc/nfs.conf doesn't exist yet. But the nfs-common systemd unit files
do exist, and the generator is run when autofs calls systemctl
daemon-reload in its postinst. Since there is no /etc/nfs.conf, the
generator exits silently.

> When the read from nfs.conf happens and the rpc_pipefs directory
> is not defined, the compiled in default rpc_pipefs directory

Or if /etc/nfs.conf isn't there, the generator exits silently.

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

Actually, I'm doing two things:
- taking out the var-lib-nfs-rpc_pipefs.mount and rpc_pipefs.target units
- taking out the bit from the generator that compares the configured
pipefs directory with the compile-time default:
--- a/systemd/rpc-pipefs-generator.c
+++ b/systemd/rpc-pipefs-generator.c
@@ -139,9 +139,6 @@ int main(int argc, char *argv[])
     s = conf_get_str("general", "pipefs-directory");
     if (!s)
         exit(0);
-    if (strlen(s) == strlen(RPC_PIPEFS_DEFAULT) &&
-            strcmp(s, RPC_PIPEFS_DEFAULT) == 0)
-        exit(0);

     if (is_non_pipefs_mountpoint(s))
         exit(1);

Therefore I'm fully relying on the generator all the time, whatever
the pipefs directory is. And my question is wouldn't this be a sane
default behavior for all users of nfs-utils, instead of having the
extra complication of having two units for each of rpc_pipefs mount
and target? Did I miss something?

Unfortunately I haven't heard back yet from the debian maintainer
about this.[4] Maybe there is a "debian packaging" way to fix this. I
also thought about systemd conditionals on /etc/nfs.conf, but then I
would probably have to add them to a bunch of units (all of them?).

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014429
2. https://salsa.debian.org/kernel-team/nfs-utils/-/blob/master/debian/nfs-common.postinst#L9
3. https://salsa.debian.org/debian/autofs/-/blob/master/debian/control#L35
4. https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/18