All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.