Hello Linux-NFS folks--
I've got an nfs4 server running linux kernel 3.1.1 with nfs-utils 1.2.4.
When an NFSv4 client connects to the server using sec=krb5p, the kernel
emits:
[ 3505.754807] RPC: AUTH_GSS upcall timed out.
[ 3505.754810] Please check user daemon is running.
It's true, i don't have rpc.gssd running on the server (though i do have
rpc.svcgssd running).
But the client can go ahead and mount the filesystem anyway, and users
with the appropriate krb5 credentials on the clients can access files on
the server based on their credentials.
So it's not clear to me what this warning is about. Should i be
running rpc.gssd on the nfs server? If so, what functionality am i
losing out on by not running it? If i don't need to run it, why is the
kernel emitting this message?
--dkg
On Thu, Dec 08, 2011 at 10:29:42AM -0500, Daniel Kahn Gillmor wrote:
> Hello Linux-NFS folks--
>
> I've got an nfs4 server running linux kernel 3.1.1 with nfs-utils 1.2.4.
>
> When an NFSv4 client connects to the server using sec=krb5p, the kernel
> emits:
>
> [ 3505.754807] RPC: AUTH_GSS upcall timed out.
> [ 3505.754810] Please check user daemon is running.
>
> It's true, i don't have rpc.gssd running on the server (though i do have
> rpc.svcgssd running).
>
> But the client can go ahead and mount the filesystem anyway, and users
> with the appropriate krb5 credentials on the clients can access files on
> the server based on their credentials.
>
> So it's not clear to me what this warning is about. Should i be
> running rpc.gssd on the nfs server?
Yes, if you're using NFSv4 then the client and server should each run
both daemons.
> If so, what functionality am i losing out on by not running it?
You lose NFSv4.0 delegations, which depend on the ability for the server
to contact the client to send delegation recalls. Delegations are
optional, so you won't lose correctness, but you may lose some
performance.
If you're using only v2, v3, or v4.1, that doesn't matter. (v2 and v3
lack delegations, and v4.1 sends callbacks over existing
client-established connections).
> If i don't need to run it, why is the kernel emitting this message?
Nevertheless I have seen that message even on machines that were running
both daemons, so I suspect there's a bug here; I haven't made it a
priority to track it down since I haven't seen it cause any actual
problems.
--b.
On 12/08/2011 12:45 PM, J. Bruce Fields wrote:
> Yes, if you're using NFSv4 then the client and server should each run
> both daemons.
ah, thanks.
>> If so, what functionality am i losing out on by not running it?
>
> You lose NFSv4.0 delegations, which depend on the ability for the server
> to contact the client to send delegation recalls. Delegations are
> optional, so you won't lose correctness, but you may lose some
> performance.
Thanks, that's useful. Do the clients need to run cachefilesd as well
to take advantage of delegation? Is there a document where i could find
this sort of information without adding noise to the list?
> If you're using only v2, v3, or v4.1, that doesn't matter. (v2 and v3
> lack delegations, and v4.1 sends callbacks over existing
> client-established connections).
OK, gotcha. Is it possible to use 4.1 with linux kernel 3.1 and
nfs-utils 1.2.5, or would i need to pull a more recent version?
Thanks, and sorry for the basic questions,
--dkg
On Fri, Dec 09, 2011 at 01:31:08PM -0500, Daniel Kahn Gillmor wrote:
> On 12/08/2011 12:45 PM, J. Bruce Fields wrote:
> > Yes, if you're using NFSv4 then the client and server should each run
> > both daemons.
>
> ah, thanks.
>
> >> If so, what functionality am i losing out on by not running it?
> >
> > You lose NFSv4.0 delegations, which depend on the ability for the server
> > to contact the client to send delegation recalls. Delegations are
> > optional, so you won't lose correctness, but you may lose some
> > performance.
>
> Thanks, that's useful. Do the clients need to run cachefilesd as well
> to take advantage of delegation?
No.
> Is there a document where i could find
> this sort of information without adding noise to the list?
Hm, it should probably be in the FAQ. I think we want to make
http://wiki.linux-nfs.org/
the place to go for Linux NFS information, so if you can't find this
under there somewhere, let's think about where to put it. Suggestions
welcomed.
> > If you're using only v2, v3, or v4.1, that doesn't matter. (v2 and v3
> > lack delegations, and v4.1 sends callbacks over existing
> > client-established connections).
>
> OK, gotcha. Is it possible to use 4.1 with linux kernel 3.1 and
> nfs-utils 1.2.5, or would i need to pull a more recent version?
It should be possible. 4.1 is somewhat new, though.
--b.
On Thu, Feb 23, 2012 at 12:58:46AM -0500, Daniel Kahn Gillmor wrote:
> On Fri, 9 Dec 2011 14:10:57 -0500, "J. Bruce Fields" <[email protected]> wrote:
> > On Fri, Dec 09, 2011 at 01:31:08PM -0500, Daniel Kahn Gillmor wrote:
> > > Thanks, that's useful. Do the clients need to run cachefilesd as well
> > > to take advantage of delegation?
> >
> > No.
>
> Is there a way that i can check to be sure that delegations are actually
> happening?
On the client I suppose you'll eventually start seeing DELEG_RETURN
calls in /proc/self/mountstats. On the server side the
nfsd4_delegations line of /proc/slabinfo should give a hint.
> What kind of performance improvement would you expect to see
> with delegatons happening on, say, a standard desktop user's homedir
> workload?
I don't know. If you get any test results that would be interesting.
--b.
On Fri, 9 Dec 2011 14:10:57 -0500, "J. Bruce Fields" <[email protected]> wrote:
> On Fri, Dec 09, 2011 at 01:31:08PM -0500, Daniel Kahn Gillmor wrote:
> > Thanks, that's useful. Do the clients need to run cachefilesd as well
> > to take advantage of delegation?
>
> No.
Is there a way that i can check to be sure that delegations are actually
happening? What kind of performance improvement would you expect to see
with delegatons happening on, say, a standard desktop user's homedir
workload?
--dkg
Are there any news in this case?
I really do not want a delay of 15 seconds. Excuse me, but this idea is just
mad.