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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.