From: Salvatore Bonaccorso <carnil@debian.org>
To: Andreas Hasenack <andreas@canonical.com>,
NeilBrown <neilb@suse.de>, Steve Dickson <steved@redhat.com>
Cc: linux-nfs@vger.kernel.org, Scott Mayhew <smayhew@redhat.com>,
Benjamin Coddington <bcodding@redhat.com>,
Ben Hutchings <benh@debian.org>
Subject: Re: [PATCH 0/2] Prefer generator to static systemd units
Date: Tue, 5 Sep 2023 17:09:33 +0200 [thread overview]
Message-ID: <ZPdErauSK2sXuh1T@eldamar.lan> (raw)
In-Reply-To: <CANYNYEEy2vf2rxLFeQ0hkstPrvF=eeA-joc0imGZt96Q+_r44w@mail.gmail.com>
Hi Steve, Neil,
On Fri, Jul 28, 2023 at 01:06:49PM -0300, Andreas Hasenack wrote:
> Hi,
>
> in Debian and Ubuntu, the configuration file /etc/nfs.conf is only
> placed on disk in the postinst script[1]. In this scenario it's possible
> to have the nfs-common generators run before /etc/nfs.conf exists[2],
> via another package's postinst calling systemctl daemon-reload. Since
> there is no /etc/nfs.conf yet, defaults are assumed and the generators
> exit silently, and the corresponding static units are used.
>
> But in Debian/Ubuntu, the rpc_pipefs directory is /run/rpc_pipefs, and
> not the one specified in the static units, and thus we get it mounted in
> the wrong directory.
>
> It seems best to always rely on the generators, as they will always be
> able to produce the correct target and mount units.
>
> For reference, this was first brought up in this thread[3].
>
> Producing an upstream set of patches was a bit confusing, since these
> systemd units are highly distro dependent. They are not even installed
> via `make install` because of this, so I have more confidence in the
> first patch of the series.
>
> I produced a Debian package with these two patches applied on top of
> Debian's 2.6.3[6], and ran the DEP8 tests of nfs-utils[4] and autofs[5],
> which exercise some simple v3 and v4 mounts, with and without kerberos.
> These tests passed[7][8] (ephemeral links, will be gone once the PPA is
> destroyed).
>
> 1. https://git.launchpad.net/ubuntu/+source/nfs-utils/tree/debian/nfs-common.postinst?h=applied/ubuntu/devel#n6
> 2. https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1971935/comments/22
> 3. https://marc.info/?l=linux-nfs&m=165729895515639&w=4
> 4. https://git.launchpad.net/ubuntu/+source/nfs-utils/tree/debian/tests?h=applied/ubuntu/lunar-devel
> 5. https://git.launchpad.net/ubuntu/+source/autofs/tree/debian/tests?h=applied/ubuntu/lunar-devel
> 6. https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+ref/upstream-nfs-utils-test
> 7. https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ahasenack-nfs-upstream-test/mantic/amd64/a/autofs/20230728_135149_0895b@/log.gz
> 8. https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ahasenack-nfs-upstream-test/mantic/amd64/n/nfs-utils/20230728_150122_3ef18@/log.gz
>
> Andreas Hasenack (2):
> Always run the rpc_pipefs generator
> Use the generated units instead of static ones
>
> configure.ac | 8 +-------
> systemd/Makefile.am | 5 -----
> systemd/rpc-pipefs-generator.c | 3 ---
> systemd/rpc_pipefs.target | 3 ---
> systemd/rpc_pipefs.target.in | 3 ---
> systemd/var-lib-nfs-rpc_pipefs.mount | 10 ----------
> systemd/var-lib-nfs-rpc_pipefs.mount.in | 10 ----------
> 7 files changed, 1 insertion(+), 41 deletions(-)
> delete mode 100644 systemd/rpc_pipefs.target
> delete mode 100644 systemd/rpc_pipefs.target.in
> delete mode 100644 systemd/var-lib-nfs-rpc_pipefs.mount
> delete mode 100644 systemd/var-lib-nfs-rpc_pipefs.mount.in
Is this patch series as prposed by Andreas acceptable upstream?
We have this change in Debian since the 1:2.6.3-1 upload,
https://tracker.debian.org/news/1442835/accepted-nfs-utils-1263-1-source-into-unstable/,
with no regression reported TTBOMK.
For reference, the patch series is here in the linux-nfs archives
(referencing it here explicitly as b4 mbox seems not to get all the 3
mails when requesting the cover letter):
https://lore.kernel.org/linux-nfs/CANYNYEEy2vf2rxLFeQ0hkstPrvF=eeA-joc0imGZt96Q+_r44w@mail.gmail.com/
https://lore.kernel.org/linux-nfs/CANYNYEFKtw+_Y-NrOoQt9G9eund2C0=XMrXBj8mt1L=ebrSkLQ@mail.gmail.com/
https://lore.kernel.org/linux-nfs/CANYNYEHETbcqmEhE7BB57bCH03J-XT986Bb+DucdpbV8KHeZug@mail.gmail.com/
Regards,
Salvatore
next prev parent reply other threads:[~2023-09-05 16:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 16:06 [PATCH 0/2] Prefer generator to static systemd units Andreas Hasenack
2023-09-05 15:09 ` Salvatore Bonaccorso [this message]
2023-11-21 19:48 ` Salvatore Bonaccorso
2023-11-22 1:17 ` NeilBrown
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=ZPdErauSK2sXuh1T@eldamar.lan \
--to=carnil@debian.org \
--cc=andreas@canonical.com \
--cc=bcodding@redhat.com \
--cc=benh@debian.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=smayhew@redhat.com \
--cc=steved@redhat.com \
/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