Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B. Funk)
Newsgroups: comp.sys.apollo
Subject: Re: why me?
Message-ID: <8904180618.AA00690@icaen.uiowa.edu>
Date: 18 Apr 89 05:42:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 38

WRT posting <13353@watdragon.waterloo.edu>

It sounds like your "SYSTYPE" environment variable for inetd
got messed up. All the "standard" Unix executable directories
(/bin /usr/bin /usr/ucb) resolve thru variant links:

     bin -> $(SYSTYPE)/bin

If SYSTYPE were not set to one of "bsd4.3" or "bsd4.2" then
none of these directories would be resolvable by the shell,
either locally or remotely. To test this out, try invoking
something that lives in /usr/apollo/bin, like bldt. That directory
doesn't depend upon the SYSTYPE. Try explicitly setting the
varaible once you've rloged in. If you could run it, printenv
would show you, but it lives in /usr/ucb. From a DM window on
that node, you could do a "ps -agew" to look at the environment
vars for the processes on that node. Note that you can't read
the environment from a remote node; "ps -agewN //name" won't work.
Check the files in /sys/node_data/etc on that node.

Another possibility, maybe the permissions on those directories
got messed up. A directory with "r" but not "x" permissions
produces some bizarre results.

One last possibility, maybe the directories themselves got messed
up. I've not seen it happen under sr10 yet, but I've seen it under
sr9.x. When directory gets wounded, things look like they're there
but can't be accessed. It usually only happens to a directory that gets
a lot of abuse, like /sys/print/queue, or a directory that is being
changed when a node crashes. The tool "/com/sald" is used to salvage
wounded directories.

Dave Funk

PS: In general, if you ever have to "blast" processes, such as at logout,
    its a good idea to reboot the node, there and then if you can.
    At least, consider the state of the machine as suspect, until you
    do get it rebooted.