From: John Hughes <john@Calva.COM>
To: Jeff Layton <jlayton@redhat.com>
Cc: Trond Myklebust <trond.myklebust@netapp.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Don't hang user processes if Kerberos ticket for nfs4 mount expires
Date: Thu, 17 Nov 2011 10:37:02 +0100 [thread overview]
Message-ID: <4EC4D5BE.2030906@Calva.COM> (raw)
In-Reply-To: <20111116144718.78b2e288@corrin.poochiereds.net>
On 16/11/11 20:47, Jeff Layton wrote:
> On Wed, 16 Nov 2011 19:14:35 +0100
> John Hughes<john@calvaedi.com> wrote:
>
>> With recent kernels if the Kerberos ticket for a nfs4 mount expires any
>> user process trying to access the mount hangs until a new ticket is
>> obtained. Simultaneously a (luckily rate-limited, but still seemingly
>> endless) stream of "Error: state manager encountered RPCSEC_GSS session
>> expired against NFSv4 server" messages is written to the kernel log.
[...]
>> This patch restores the old behavior, which makes nfs4 mounted home
>> directories usable for me.
>>
> Uhhh, no...EKEYEXPIRED was never passed to userland. The patchset that
> added EKEYEXPIRED returns in this codepath also added the code to make
> it hang.
You are, of course, right. userland used to get EPERM.
> This not a bug, or at least it's intentional behavior. When a krb5
> ticket expires, we *want* the process to hang. Otherwise, people with
> long running jobs will often find that their jobs error out
> inexplicably when their ticket expires.
I thought that was what kstart/krenew were for.
> The patches that introduced this behavior went into 2.6.34. See the
> commits around 2c64348 (and some preceding ones in the rpc layer).
Ah, I'm a Debian user - 2.6.32 for the moment, soon to be 3.?
> If you want to fix this use case, you'll need to come up with a scheme
> that doesn't regress this behavior. I think that you'll really need to
> ensure that whatever process you expect to re-fetch your TGT is not
> dependent on accessing kerberized nfs mounts. That really seems like an
> untenable chicken and egg situation.
Ow. "Fixing" (at least) Gnome-3 and Gnome-2 screen-lock/screensavers.
How about a mount option to chose between the two behaviours?
next prev parent reply other threads:[~2011-11-17 9:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 18:14 [PATCH] Don't hang user processes if Kerberos ticket for nfs4 mount expires John Hughes
2011-11-16 19:47 ` Jeff Layton
2011-11-16 23:44 ` Jim Rees
2011-11-17 1:31 ` Jeff Layton
2011-11-17 1:38 ` Jeff Layton
2011-11-17 11:05 ` John Hughes
2011-11-17 13:13 ` John Hughes
2011-11-17 21:46 ` Jeff Layton
2011-11-18 1:51 ` Jim Rees
2011-11-18 2:03 ` Jeff Layton
[not found] ` <4EC62325.1060009@Calva.COM>
2011-11-18 12:50 ` Jim Rees
2011-11-17 1:46 ` Matt W. Benjamin
2011-11-17 9:37 ` John Hughes [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-11-18 17:16 Myklebust, Trond
2011-11-18 17:54 ` Jim Rees
2011-11-18 18:23 ` Trond Myklebust
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=4EC4D5BE.2030906@Calva.COM \
--to=john@calva.com \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.com \
/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.