Linux NFS development
 help / color / mirror / Atom feed
From: Carlos Maiolino <cem@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	 "Darrick J. Wong" <djwong@kernel.org>,
	zlang@kernel.org, linux-xfs@vger.kernel.org,
	 fstests@vger.kernel.org, jack@suse.cz,
	Chuck Lever <cel@kernel.org>,
	 linux-nfs@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] common/nfs: add management helpers
Date: Thu, 10 Sep 2026 13:40:44 +0200	[thread overview]
Message-ID: <aqKWMY5yebKmUE6_@andromeda.toxiclabs.cc> (raw)
In-Reply-To: <208df4dabcb9db9c6c7d00f4cf2f63fa3be815e1.camel@kernel.org>

On Thu, Sep 10, 2026 at 07:30:46AM -0400, Jeff Layton wrote:
> On Tue, 2026-09-08 at 23:12 -0700, Christoph Hellwig wrote:
> > On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > > +# Start rpcbind if it is not already running.
> > > > +_start_rpcbind()
> > > > +{
> > > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > > 
> > > Aren't these daemons usually configured as system services?
> > > 
> > > # service rpcbind start
> > > 
> > > etc?
> > 
> > They usually are, but doing that as part of a test feels wrong.
> > Adding the relevant maintainers and list.
> > 
> > 
> 
> I don't see a problem with using the normal systemd services as long as
> you're just doing a "start" instead of an "enable". That would be a lot
> less likely to bitrot than these scripts.

My only concern regarding using systemd services is portability. I tried
to keep the test agnostic to the init system being used, but it indeed
would be way easier to put this into xfstests if we just accept this
will be a __not_run on systemd-less distros. Giving the majority of
people I know frequently running xfstests (including me) uses
systemd-based distros, this wouldn't be a problem for me personally...

> 
> > > > +}
> > > > +
> > > > +# Stop rpcbind.
> > > > +_stop_rpcbind()
> > > > +{
> > > > +	pkill rpcbind 2>/dev/null
> > > > +}
> > > > +
> > > > +# Start the NFS server if not already running.
> > > > +_start_nfsd()
> > > > +{
> > > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > > +}
> > > > +
> > > > +# Stop the NFS server.
> > > > +_stop_nfsd()
> > > > +{
> > > > +	rpc.nfsd 0 2>/dev/null
> > > > +	pkill rpc.mountd 2>/dev/null
> > > 
> > > If the system under test has nfs filesystems mounted, won't killing
> > > those daemons also break the mounts?
> > > 
> > > I think that might break testing of nfs itself, and nfs-booted testing
> > > nodes as well?
> > 
> > Possibly.  I guess if we want to save we need to launch a container
> > or at least a network namespace this is bound too. 
> 
> Doing this in a container would be better and less likely to interfere
> with other stuff running on the box. Our container isolation is still
> not 100% perfect with nfsd (there is still a global mutex, etc.), but
> we're getting closer.
> 
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

  reply	other threads:[~2026-09-10 11:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260907164054.111393-1-cem@kernel.org>
     [not found] ` <20260907164054.111393-2-cem@kernel.org>
     [not found]   ` <20260908142226.GL839663@frogsfrogsfrogs>
2026-09-09  6:12     ` [RFC PATCH 1/2] common/nfs: add management helpers Christoph Hellwig
2026-09-09 16:13       ` Darrick J. Wong
2026-09-10  9:45         ` Carlos Maiolino
2026-09-10 11:30       ` Jeff Layton
2026-09-10 11:40         ` Carlos Maiolino [this message]
2026-09-10 11:48           ` Jeff Layton
2026-09-10 11:34 ` [RFC PATCH 0/2] quota evasion test and nfs helpers Jeff Layton

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=aqKWMY5yebKmUE6_@andromeda.toxiclabs.cc \
    --to=cem@kernel.org \
    --cc=cel@kernel.org \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@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