[18258] in Athena Bugs

home help back first fref pref prev next nref lref last post

sun4 8.3.23: kinit

daemon@ATHENA.MIT.EDU (Eric Mumpower)
Tue Sep 12 11:24:45 2000

Message-Id: <200009121524.LAA23503@denmark-vesey.mit.edu>
To: bugs@MIT.EDU
Date: Tue, 12 Sep 2000 11:24:41 -0400
From: Eric Mumpower <nocturne@MIT.EDU>

System name:		denmark-vesey.mit.edu
Type and version:	SPARC/5 8.3.23 (with mkserv)
Display type:		cgsix

Shell:			/afs/sipb/project/tcsh/tcsh
Window manager:		/mit/windowmanagers/sun4bin/vtwm.gamma -f /mit/nocturne/dotfiles/vtwmrc

What were you trying to do?

Run kinit.

What's wrong:

I ran 'kinit' as part of an invocation of "eval `tkswap athena`" which I
have aliased to "knorm". For completeness, though I don't think it's
relevant as the script is fairly straightforward (and certainly shouldn't be
doing anything itself that locks the ticketfiles) and has never had this
happen before, "tkswap" can be found at /mit/nocturne/scripts. (As you might
guess, NOCTURNE_LOCALE was set to "athena".)

Here's the error:

> [...]
> Password for nocturne@ATHENA.MIT.EDU: 
> Kerberos 4 error: Can't lock ticket file; try later (tf_util)
> kinit: File name too long trying to save the V4 ticket

As you can see, it left my krb4 tickets in a strange state:

> denmark-vesey% klist
> Ticket cache: /tmp/krb5cc_606
> Default principal: nocturne@ATHENA.MIT.EDU
> 
> Valid starting     Expires            Service principal
> 09/12/00 11:10:11  09/12/00 21:10:08  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
> 
> 
> Kerberos 4 ticket file: /tmp/tkt606
> klist: can't find realm of ticket file: Generic kerberos error (kfailure)

It might be worth pointing out that "klist -s" at this point returned
true. Is that appropriate? Are krb4 tickets that insignificant in our
environment? This might be an oversight/bug in itself.

> denmark-vesey% od -c /tmp/tkt606 
> 0000000   n   o   c   t   u   r   n   e  \0  \0
> 0000012

(I.e. the krb4 ticket file consisted of "nocturne" followed by two nulls.)

A subsequent "kinit nocturne" encountered no similar problem, of course.

The only process I'm aware of having been running at the time which I can
imagine had anything to do with this was zwgc. I don't think "zmailnotify"
could have been involved, as I believe my PO server went to the new-format
mail-notification a while back and my .maillock hasn't been touched since
February.

What should have happened:

  Klist should have worked, as usual. :-)

Please describe any relevant documentation references:


home help back first fref pref prev next nref lref last post