doctor1@ihlpa.att.com (Patrick B Hailey) (11/04/90)
I don't regularly read this group, as the administration of Suns is only
peripheral to my job. I have been 'lurking' for a few days, however. If
this has been discussed to death or if this is not the proper newsgroup,
please accept my apologies.
We run a number of Suns as servers, with non-Sun terminals connected to
tty-a for system consoles. As you know, the Suns are very touchy about
their consoles: Turning them off or pressing 'Break' (Disconnect) causes
the system to abort.
We also run a system for remote management and monitoring of our mini
computers, which requires connecting a terminal tap between the system
console and the machine. If you plugged another terminal into this tap,
you would have two terminals acting as the console, unbeknownst to the
machine. We, however, connect this tap to the computer running the remote
management/monitoring software.
The problem is this: If the serial ports on the monitoring machine are
powered down (like if there's a power outage), all the Suns connected to
the monitoring system are aborted. Sorry, we don't know whether the
monitor actually sends a break, or if it sends garbage that the Suns
interpret as a break.
I am aware of a fix for the Sun's general touchiness concerning its
console, which involves connecting certain pins of the console connecter
with a resister (sorry, don't have the specifics in front of me). Other
sites using the same monitoring system, however, report that it doesn't
help in this case (a mystery in itself).
Before I have to find the resources to analyze exactly what we're sending
down the line when we take a power hit, I thought perhaps someone on
usenet might have a guess as to what's happening here, and/or have some
idea for a solution. At this point, I'd even be glad to find out how to
inhibit aborts under any circumstances (that is, even when you need to
abort a hung system).
Is the Break=Abort strictly a hardware thing, or is there a simple,
unobtrusive (i.e. won't confuse any other hardware/software) kernel mod
that would allow us to choose another signal as the abort instruction?
The 'monitoring system' is AT&T's CompuLert (TM AT&T) running on an AT&T
3B20, though I'm told it affects 3B2 CompuLerts as well.
Finally, and not too importantly, I'm curious as to whether anyone can
defend this design. Is it clever to have such an easily generated signal
(noise from a line adjacent to the console's comes to mind) cause such a
devastating instruction to be performed?
If it sounds like I don't fully understand the problem, you're right.
Any and all enlightening comments are welcome.
Thanks awfully,
Patrick B. Hailey