Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2026-09-10 at 13:40 +0200, Carlos Maiolino wrote:
> 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...
> 

That's what I'd probably do. If someone wants to step up and do
something for non-systemd distros then they can have at it.

Alternately, you could use systemd and just fall back to what you're
doing now in the case where it's not present. My only fear there is
that the non-systemd cases would probably bitrot because no one would
use them.

That said, if you're doing all of this in a container then it shouldn't
matter much how it gets started.

> > 
> > > > > +}
> > > > > +
> > > > > +# 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"

If you do decide to go this route, note that rpc.nfsd is being
deprecated. We have a new tool for managing the server now called
"nfsdctl" that you probably want to use when possible.

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

-- 
Jeff Layton <jlayton@kernel.org>