> | > "locking up" is such a poorly defined term...
> |
> | Forgive me, but after reading the posts on this subject I have gotten
> | into the habit of assuming that the term would be self-explanatory as in
> | "machine looks fine but I can't get any input into it via the keyboard
> | or mouse," that is, it has "locked me out!"
Much thanks for your reply. Indeed, there are many things I left out of
the message you quote, maily for lack of space and for not wanting to
provide too many details at once (even though the Devil _is_ in those
details). Interleaved with your thoughtful reply are my answers to your
questions:
Quote:> The question here is what do you see when you login over the network?
I can login over the network. I can start any application in a telnet
window that pops an X window on my remote console (i.e., jot, showcase,
imageworks, etc.). However, because I had edited my X scripts (those
that reside in /var/X11/xdm) so that no external host had access to my
console ("/usr/bin/X11/xhost -"), I could not remotely start any X
windows. A few days ago, I changed that and I, accidentally, started a
remote session while wrongly trying to execute the command
showfiles -c -m -s | tar cvf "filename"
which, incidentally, did not work as it produced a 0 length file (why?).
So, yes, I can pop an X-window in my remote display.
Quote:> Can you pop up a new window? What does a par on the X server show (anything,
> or nothing)? If you start killing graphics programs one by one, do things
It produces all kinds of output which I don't understand. I invoked
par -s -SS Xsgi
and the first output lines are:
0mS was sent signal SIGUSR1
2mS END-pause() errno = 4 (Interrupted system call)
2mS received signal SIGUSR1
2mS sigreturn(0x7fffaa68) OK
3mS execve(/usr/sbin/Xsgi, 0x7fffaf10, 0x7fffaf18) errno = 2 (No
such file or directory)
7mS execve(/usr/bsd/Xsgi, 0x7fffaf10, 0x7fffaf18) errno = 2 (No such
file or directory)
.
.
etc....
I hope that you had this in mind.
Quote:> start working? Does the vulcan death grip work? If you turn off nfs,
There are no graphics programs working at this time (only MediaMail, but
whether it runs or not, does not make any difference to the graphics
hang problem). As for turning nfs off, I did not think of it since
nobody else is using the machine and the nsf mounted disks are not being
accessed (nfs is on because our last graduate student set it up).
Quote:> does the problem disappear? (I know in this specific case you said the
> vulcan death grip works.)
> The symptoms could be a graphics or an X bug, or simply a program
> grabbing the X server, or the input focus, and that program being buggy
> (possibly including something that we ship).
As I said elsewhere, the problem came out of left field since the system
had been running stably for years (for sure since we upgraded to 5.3).
The only graphics program running locally at the onset of the problem
was MediaMail. The system was also being used to display a remotely-ran
Netscape (runs faster in our Indigo^2). This configuration had been
used for months if not years. The only possibility of a problem with our
graphics system has been a message that shows up in the SYSLOG after the
graphics system is restarted (either via a reboot or by stop/ster gx)
for quite some time now (years?) that says:
Dec 29 11:59:37 2A:hobbes unix:
Dec 29 11:59:37 2A:hobbes unix: gm-2 (configured for IP7/9) $
Dec 29 11:59:37 2A:hobbes unix:
Dec 29 11:59:37 2A:hobbes unix: Warning: EEprom Vof is out of date.
Dec 29 11:59:37 2A:hobbes unix: Warning: Reloading EEprom with default
60Hz Vof.
Dec 29 11:59:37 2A:hobbes unix: DEBUG_NOISE at 0x9806F116
But the system has always performed acceptably until now. Of course,
there is the fact that clogin works properly (I tested xdm by renaming
it, and of course, the clogin screen never showed up until I restored,
via a telnet session, xdm's original name) and takes mouse and keyboard
commands.
Since MediaMail shows up very reliably on a remote system, I don't think
that it is the program itself that is buggy.
There is one added piece of evidence that suggests that a daemon is
going to sleep or that a configuration file is corrupt: while the
desktop is coming up, I am sometimes able to gain focus of an open
winterm by clicking on it while things are coming up. Thereafter, the
winterm will take keyboard input but will not obey any of the X
commands, either via mouse clicks (no menu pops if the left-upper button
is clicked, does not iconify or expand if the corresponding buttons are
pressed) or keyboard shorcuts (e.g., ALT-F9 does not cause the window to
iconify). If I don't do it at the right time, I can't access any
windows. So, which daemon or script is messed up?
Quote:> In my narrow view of the world, I'd call this a "graphics hang", or
> the like, since the system is probably still alive. On the other hand,
Correct. The system is very much alive. My apologies for not being
sufficiently precise.
Quote:> if you can't get to it over the net, then I'd say the whole system
> is hung (although I'd always like a serial console check in those cases,
> when possible).
Point taken. Again, thank you very much for your interest.
--
* J. Manuel Urrutia | En tierra de ciegos, *