On Mon, 2008-11-03 at 17:33 -0500, Kevin Coffman wrote:
>
> Once again, this is all from librpcsecgss. No messages originating
> from rpc.gssd itself here.
Not sure why. FWIW,
>
> > Nov 3 15:17:33 linux krb5kdc[5006]: TGS_REQ (1 etypes {1}) 10.75.22.1: ISSUE: authtime 1225740577, etypes {rep=1 tkt=1 ses=1}, brian@ILINX for nfs/linux.interlinx.bc.ca@ILINX
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: leaving poll
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: handling null request
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: sname = brian@ILINX
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: DEBUG: serialize_krb5_ctx: lucid version!
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: doing downcall
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: mech: krb5, hndl len: 4, ctx len 85, timeout: 2147483647, uid: 1001, gid: 1001, num aux grps: 13:
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 1) 1001
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 2) 117
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 3) 1010
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 4) 1011
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 5) 2000
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 6) 29
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 7) 20
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 8) 24
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 9) 25
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 10) 30
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 11) 44
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 12) 46
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: ( 13) 111
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: sending null reply
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: writing message: ...
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: finished handling null request
> > Nov 3 15:17:33 linux rpc.svcgssd[13724]: entering poll
>
> If you can get
> a packet trace between the client and server during the mount /
> context negotiation, check the NULL reply from the server for this
> error code.
Well, this is just it.
# mount -t nfs4 -s -o sec=krb5i,rw,intr,rsize=8192,wsize=8192 linux:/home/share /mnt/test
on the client does not result in any NFS4 traffic between the client and
the server. In fact if I ^C the above mount and issue it again, I don't
get another gss/svcgssd upcall. Is there some kind of caching going on?
How can I invalidate the cache? Probably it's moot though given that
this sequence of events is not resulting in any NFS4 traffic anyway.
This was all working before last night, then all of a sudden, it
stopped. Nothing remarkable happened at the time that
could/should/would have caused this silliness. ~sigh~
b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
