From: bfields@fieldses.org (J. Bruce Fields)
To: Chris Hall <linux-nfs@gmch.uk>
Cc: linux-nfs@vger.kernel.org
Subject: Re: mount.nfs4 and logging
Date: Wed, 23 Sep 2020 10:40:56 -0400 [thread overview]
Message-ID: <20200923144056.GB4691@fieldses.org> (raw)
In-Reply-To: <eb64e66e-0328-f9e6-7511-1b73f67c49c1@gmch.uk>
On Mon, Sep 21, 2020 at 03:40:01PM +0100, Chris Hall wrote:
> On 20/09/2020 20:32, J. Bruce Fields wrote:
> >On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
> ...
> >>Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
> >>but are not bound to any ports.
>
> >That looks good. (And rpc.mountd does still serve a purpose in the
> >NFSv4 case, answering requests from the kernel for information related
> >to exported filesystems.)
>
> >>But rpc.statd and rpcbind have also been started, and various ports
> >>have been opened, including port 111 which is bound to systemd. Is
> >>there a way to inhibit that for nfs4 only ?
>
> >Unlike rpc.mountd, there's no reason for those to be running at all.
> >You can mask thoe corresponding systemd units.
>
> I tried masking all of: rpcbind.socket, rpcbind.service,
> statd.service and statd-notify.service. systemctl start
> nfs-server.service (eventually) gives, according to the logging:
>
> nfs-mountd.service: start operation timed out. Terminating.
> nfs-mountd.service: State 'stop-sigterm' timed out. Killing.
> nfs-mountd.service: Killing process x (rpc.mountd) with signal SIGKILL.
> nfs-mountd.service: Control process exited, code=killed, status=9/KILL
Huh, that suggests rpc.mountd is trying to contact rpcbind, but if
you've got v2/v3 turned off in the configuration files, it shouldn't be
trying to register anything.
Looking at the code.... I wonder if the problem is the unregistration
added by 849b7072a049 "mountd: Clear mountd registrations at start up"?
> If I unmask rpcbind.service, I can start nfs-server. It no longer
> starts rpc.statd. But I still have rpcbind running and port 111
> open.
>
> >It'd be nice if there was a way to make that happen automatically if v2
> >and v3 are configured out in the configuration files, but I don't know
> >how to make that happen.
>
> It would and me neither.
I suppose they could check the configuration and exit on startup if they
see they're not needed. Will systemd notice they died and try to
restart them or something?
--b.
prev parent reply other threads:[~2020-09-23 14:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1725851AbgIKKt5/20200911104957Z+185@vger.kernel.org>
2020-09-11 11:45 ` mount.nfs4 and logging Chris Hall
2020-09-14 18:30 ` Steve Dickson
2020-09-15 13:06 ` Chris Hall
2020-09-16 12:52 ` Kenneth Dsouza
2020-09-16 14:31 ` Kenneth Dsouza
2020-09-16 17:31 ` Kenneth Dsouza
2020-09-19 16:33 ` J. Bruce Fields
2020-09-19 16:40 ` J. Bruce Fields
[not found] ` <12298172-f830-4f22-8612-dfbbc74b8a40@gmch.uk>
2020-09-20 19:32 ` J. Bruce Fields
2020-09-21 14:40 ` Chris Hall
2020-09-23 14:40 ` J. Bruce Fields [this message]
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=20200923144056.GB4691@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@gmch.uk \
--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