linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Dickson <steved@redhat.com>
To: Benjamin Coddington <bcodding@redhat.com>,
	Andreas Hasenack <andreas@canonical.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Why keep var-lib-nfs-rpc_pipefs.mount around?
Date: Sat, 23 Jul 2022 13:29:17 -0400	[thread overview]
Message-ID: <7bfafe56-0c13-a32d-093b-4d3684c4f2c7@redhat.com> (raw)
In-Reply-To: <EE39279C-4E40-48C8-ABC9-707EB1AD6D79@redhat.com>

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


  reply	other threads:[~2022-07-23 17:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 16:50 Why keep var-lib-nfs-rpc_pipefs.mount around? Andreas Hasenack
2022-07-11 13:13 ` Benjamin Coddington
2022-07-23 17:29   ` Steve Dickson [this message]
2022-07-25 12:38     ` Andreas Hasenack
2023-07-09  7:38       ` Always run rpc-pipefs-generator generator (was: Re: Why keep var-lib-nfs-rpc_pipefs.mount around?) Salvatore Bonaccorso
2023-07-10 14:39         ` Benjamin Coddington
2023-07-24  9:12           ` Salvatore Bonaccorso
2023-07-24 13:13             ` Andreas Hasenack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7bfafe56-0c13-a32d-093b-4d3684c4f2c7@redhat.com \
    --to=steved@redhat.com \
    --cc=andreas@canonical.com \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).