From: Stephen Hemminger <stephen@networkplumber.org>
To: "J. Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Fw: [Bug 208451] New: NFS server occasionally spontaneously reboots when client mounts exported directory
Date: Mon, 6 Jul 2020 16:41:31 -0700 [thread overview]
Message-ID: <20200706164131.78e0a4ef@hermes.lan> (raw)
Begin forwarded message:
Date: Mon, 06 Jul 2020 02:11:42 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 208451] New: NFS server occasionally spontaneously reboots when client mounts exported directory
https://bugzilla.kernel.org/show_bug.cgi?id=208451
Bug ID: 208451
Summary: NFS server occasionally spontaneously reboots when
client mounts exported directory
Product: Networking
Version: 2.5
Kernel Version: 5.7.7
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: nanook@eskimo.com
Regression: No
This may be related to bug #208157. From 5.7.0 through 5.7.4, nfs-server
would not start upon boot on one of my servers.
With 5.7.7 this was resolved BUT now when I reboot one of the NFS clients
or unmount and remount an NFS partition on the client, the NFS server will
sometimes spontaneously reboot.
I get these messages in /var/log/dmesg.0:
(The old dmesg log I assume is relevant since it would be the active one
before the last boot).
[ 40.302192] systemd[1]: Mounting NFSD configuration filesystem...
[ 40.688313] kernel: RPC: Registered tcp NFSv4.1 backchannel transport
module.
[ 69.899630] kernel: NFSD: Using UMH upcall client tracking operations.
[ 69.899635] kernel: NFSD: starting 90-second grace period (net f00000a8)
After the NFS server reboots I see these NFS related messages in dmesg:
[ 53.810062] systemd[1]: Mounting NFSD configuration filesystem...
[ 54.254326] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 106.468779] NFSD: Using UMH upcall client tracking operations.
[ 106.468781] NFSD: starting 90-second grace period (net f00000a8)
[ 107.631713] NFS: Registering the id_resolver key type
[ 110.815312] NFS4: Couldn't follow remote path
[ 113.935404] NFS4: Couldn't follow remote path
[ 117.055421] NFS4: Couldn't follow remote path
[ 120.175488] NFS4: Couldn't follow remote path
[ 123.295611] NFS4: Couldn't follow remote path
[ 126.415625] NFS4: Couldn't follow remote path
[ 129.545752] NFS4: Couldn't follow remote path
[ 132.655844] NFS4: Couldn't follow remote path
So pretty much the same thing except for the "NFS4: Couldn't follow remote
path" messages which I've read are caused by old nfs-utils not using the new
system calls so probably not relevant.
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2020-07-07 0:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20200706164131.78e0a4ef@hermes.lan \
--to=stephen@networkplumber.org \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox