Hi,
First, I'd like to say that the people on sun-managers are fantastic! I got
heaps of replies which tracked down the problem easily. Thanks to everyone
who replied!
Here's the original problem:
>We're running SunOS 4.1 on a 4/470. Recently we've been having lots of
>problems with our console--a vt220 terminal. At apparently random times
>the console will hang, that is it will stop accepting input, and
>will stop printing any messages which are sent to the console (eg "su
>succeeded for blah ...."). On one occasion it "came back to life" after
>a few hours and started working normally but usually we need to reboot
>it to get it going again.
>
>Apart from the console not responding there seem to be no other
>symptoms to indicate any problems, the Sun works completely normally
>otherwise. Killing getty on the console doesn't seem to help either
>when it gets in that state.
---- I received various possible solutions to the problem I mentioned. For completeness--and because they seem to be common problems--I'll summarise all of them (not just the one which solved our hassle).*** (1) "Console Grabbing" Process (eg xterm -C).
Some windowing programs (eg xterm, cmdtool) have an option (-C) to grab the output (& input!) from the console and connect it to the process in question. This is great if you happen to be on the console itself (it stops your screen being messed up by normal console messages) but if you're remotely logged in you "hijack" the real console and make it useless. This is what was causing the problem we had.
If you're having similar problems on a system which serves users who use windowing environments this is probably the cause. You can check this by running "ps waux | egrep -e -C" and looking for terminal emulators (eg xterm, cmdtool). When the process dies control goes back to the console.
Bruce Rossiter also suggests: > If you are interested, do a 'man console' and look at the TIOCCONS >ioctl (it implies that you can also write a simple program that opens >/dev/console and does a TIOCCONS ioctl on it, which might be a simpler way >to restore the console. I haven't had time to play with it yet.). It also >has the nice BUGS section that tells you that TIOCCONS is insecure.
The usual cause of someone running with -C when they're NOT on the console is that they have simply copied their X (or SunView) init files from another user (or default) and not checked them. If you have alot of users doing this, it might well be worth it to try one of the following suggestions. (i) [From: Claude Scarpelli] Change your xterm, cmdtool, etc to a simple script which removes the -C flag from the argument list before executing the "real" terminal emulator.
(ii) [From: Rich Scott] Cure when SunView executed remotely on a fileserver--which doesn't have a Sun monitor as console!
>One thing that I did >to defeat people being able to even *start* a Sunview process on the >fileserver console is to remove a couple of device files on the fileserver: > > /dev/fb (framebuffer) > /dev/bw* (b/w screen) > /dev/cg* (color screens) > > This way, Sunview exits immediately, since it can't find the device >files it needs. SunOS will run perfectly fine w/o these files, since your >terminal console uses only /dev/console and /dev/tty{whatever}. And of course, >if you upgrade to a Sun monitor (kind of silly on a fileserver, imho), you >can always do a MAKEDEV to replace the above files. This stopped a *lot* of >console hangs on our machines.
*** (2) Ctrl-S and Ctrl-Q
Someone has accidently hit Ctrl-S (hold screen), typing Ctrl-Q should fix it up if this is the problem.
*** (3) Getty running on BOTH console and ttya (check /etc/ttytab).
Daniel Trinkle (one of many helpful people) notes: > A recent poster had a problem with gettys configured on both >/dev/console and on /dev/ttya (two names for the same thing if you are >using ttya port for the console). You should check /etc/ttytab.
Make sure that the 4th field (which has a on/off value) has only *one* of the console & ttya lines set to on.
*** (4) Miscellaneous.
Barry Shein: >The other possibility is a flow control, vt220's can't really keep up >with 9600 so if something's not quite right in the set-up on either >end (vt220 or sun tty line) it can get hung when the 220 ^S's.
David St Pierre: >I have a C ITOH console on a 370 which misbehaves similarly. >If left unattended, the syslog messages displayed on the console >(without intervening keyboard input) seem to fill up a comms buffer. >I just occasionally go in and reset/clear the terminal comms buffer.
Ron Vasey: >Be sure flow control is disabled on both the SUN port and in the terminal. >Also that any "required" control/handshake lines (DTR, CTS, CD, etc.) are >either disabled or pulled high -- with jumpers in the cable if necessary. >Also see man (8) ttysoftcar and see if that applies. Hope this helps!
Charles McGrew: >Offhand, I'd suggest you have a look at the serial cable -- perhaps >it is going bad? (You may want to swap the terminal and see if that's >what's wrong -- worst case is the serial port on the sun, but most likely >the cable...)
---- Thanks again to all that replied:
Anthony A. Datri Sam Fulcomer Dennis Morse Bruce Rossiter Barry Shein David St. Pierre Sjoerd Mullender Rich Scott George Ross Ron Vasey John Hasley Charles (McGrew?) Marc Cohen Matt Cohen Len Evens Guy Harris Brian Field Joe Pruett Daniel Trinkle Blair MacIntyre Claude Scarpelli VINCE@uconnvm.bitnet
Eric. -------------------------------------+--------------------------------------- Eric Halil |Internet/CSnet: eric@cc.uq.oz.au Prentice Computer Centre |Bitnet: eric%cc.uq.oz.au@uunet.uu.net University of Queensland 4072 |UUCP: uunet!munnari!cc.uq.oz!eric AUSTRALIA -- Phone: +61 7 377 3022 |JANET: eric%cc.uq.oz.au@uk.ac.ukc
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT