[3930] in Athena Bugs
Re: vax 6.4R: xclock
daemon@ATHENA.MIT.EDU (probe@ATHENA.MIT.EDU)
Tue Jan 9 15:20:56 1990
From: probe@ATHENA.MIT.EDU
Date: Tue, 9 Jan 90 15:20:38 -0500
To: tarquin@ATHENA.MIT.EDU
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: Robert P Poole's message of Tue, 09 Jan 90 14:53:52 EST,
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
Date: Tue, 09 Jan 90 14:53:52 EST
From: Robert P Poole <tarquin@ATHENA.MIT.EDU>
System name: test-2000
Type and version: VAXSTAR 6.4R
Display type: SM
What were you trying to do?
My .startup.X file contains the command:
xclock -rv -chime -analog -geometry -15+10 &
What's wrong:
The program will not start; a message is printed in the console window:
/usr/bin/X/xclock: Permission denied.
What should have happened:
The program should have started.
Please describe any relevant documentation references:
Yesterday, I complained that xload would not start up on the machine Test-3100.
I now believe there is a pattern developing here; it seems that version 6.4R is
having trouble executing processes that are in the .startup.X file, but I am
now convinced that the problem does not reside with any specific program. It
should also be noted that yesterday, when on Test-3100, I ran xload
independently from my xterm, and it functioned fine.
Was this shortly after an "attach" of an AFS filesystem, such as SIPB?
There seems to be a window of time once there is an authentication to
the AFS cell that a contact to the fileserver seems to not like the new
AFS tokens. This is generally seen if you background an "attach" of AFS
filesystems. (This is one of the many bugs that are known to exist with
AFS, which is why the filesystem is still under evaluation).
-Richard
