[4849] in testers
Re: Strange sometime failure in .startup.X
daemon@ATHENA.MIT.EDU (Camilla R Fox)
Wed Jun 20 15:59:29 2001
Message-Id: <200106201959.PAA02804@red-herring.mit.edu>
To: testers@MIT.EDU, cana@MIT.EDU
In-Reply-to: <Pine.LNX.4.30L.0106200930290.1472-100000@kinki-sharyo.mit.edu>
Date: Wed, 20 Jun 2001 15:59:24 -0400
From: Camilla R Fox <cfox@MIT.EDU>
> I find this intensely odd, considering that the one that fails is the
> _second_ invocation of xterm-color, and the first one succeeds. Running
> the same command by hand after startup completes works fine. If this is
> something obvious, I'm overlooking it. It also doesn't happen on 8.4
> machines.
I've been seeing the same failure, with zcrypt from outland, on 9.0
linux; I didn't report it before, because I was trying to narrow down
the circumstances under which it happens.
My usual login session has a long running screen session with two
copies of vt running in it. Each are subscribed to a fairly quiet
zcrypted class. When a zephyr comes in on it, one of the zwgcs prints
zwgc: unable to exec /afs/sipb.mit.edu/project/outland/bin/zcrypt: No such file or directory
and displays the zephyr still encrypted, while the other one decrypts
the zephyr correctly.
Destroying my tickets and tokens and getting new ones doesn't provoke
the failure mode again, but if, with valid tickets and tokens, I run
fs flushvolume /mit/outland/bin
it does fail as before, on the next zephyr.
Using this method, I can't reproduce the failure on 9.0 solaris.
Under normal usage, I tend to see the failure once or twice a day,
which is presumably how often the program falls out of my cache.
I can still reproduce the failure if I get rid of my sipb cell tokens.
-Camilla
