Date: Sun, 24 Dec 2023 15:50:38 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 275905] nfs client: mount becomes unresponsive Message-ID: <bug-275905-3630-LDeu2g8Was@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275905-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-275905-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275905 --- 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? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275905-3630-LDeu2g8Was>