[Bug 275905] nfs client: mount becomes unresponsive
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 24 Dec 2023 15:50:38 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275905
--- Comment #4 from Rick Macklem <rmacklem@FreeBSD.org> ---
The renew thread RPC (the one that your backtrace shows
as hung in nfsv4_sequencelookup()) would be using the
host/FQDN@REALM entry in the default /etc/krb5.keytab.
(ie. Your TGT would not be used for this, since the
renew thread runs as "root".)
Could the client's keytab entry be broken somehow?
(As you probably are aware, when you create a new
keytab for a principal, old keytabs no longer work.)
You could go onto the client and do
# kinit -k host/FQDN
to see that the keytab entry for "host" works ok.
(I am still wondering what will happen if the TGT
for the keytab expires just after the RPC request
is sent to the server. I'll look into that.)
There could also be a problem where other RPCs were
using all slots, so the renew thread slept in
nfsv4_sequencelookup() and then another thread needed
the renew thread to do some work.
--> The renew thread should really have a dedicated
slot in the NFSv4 session, so that no other thread
can cause it to block.
--> I might work on a patch for that.
Does this hang occur frequently or was this a "one time"
hang on a mount that usually behaves ok?
--
You are receiving this mail because:
You are the assignee for the bug.