🚀 go-pugleaf

In article <5586@brazos.Rice.edu> idall@augean.ua.OZ.AU (Ian Dall) writes:
>X-Sun-Spots-Digest: Volume 9, Issue 73, message 8
>
>We are seeing an interesting problem on our Sun 4's running SunOs 4.03.
>Sometimes pty's seem to become stuck in some funny state so that anything
>that tries to write to them dies. I see this most often with emacs
>sub-processes but sometimes it also prevents rlogins....

I've seen this a couple of times in here and on sun-managers.  The problem
shows up here, too.  We have a SUN 4/370 in a server configuration running
4.0.3.  All of the terminals except the console (tvi970 on ttya) are
connected through a Xylogics Annex II ethernet t erminal server on the
local net.  It shows up as rlogin refusal with the response "Connection
closed".

The SUN hotline guy I talked to said there was a known bug (ID# 1014706)
causing this.  I would appreciate it if someone could confirm that.  That
bug is supposed to be fixed in 4.1 (according to mr. hotline).  The
workaround I use is this:

o   look at 'who' to see which tty is hung up.  It's usually the first one
    missing in an otherwise continuous list of assigned ttys.  If not, it
    would be the next one in the series.

o   remove the entry for that tty in /etc/ttytab

o   remove the corresponding tty and pty entry in /dev

o   kill -HUP 1 to reset init

This is a small hassle.  When you reboot, you have to remember to put the
tty/ptys back that you removed.  You will have to reboot eventually, since
this workaround guarantees that you will eventually run out of ttys.

The other fixes are to reboot, or as Ian said, capture the process with
the offending tty attached and stash it. 

Some sun-managers responded when I sent this out to them.

Brian Parent <bparent@ucsd.edu> said:
>
>Your fix sounds a bit more drastic than what I've found
>to work.  I find out what other processes are running on
>the offending tty, and kill them off.  Thats it.

Andy Sherman (andys@ulysses.att.COM) said:
>
>I've got a tip on how to handle restoration without having to strain
>your memory.  I have a file on all my systems called /etc/nextboot.
>When I need for something to happen on the next boot, I put it in there.
>A section in /etc/rc.local runs the file and then clears it.

Any @SUN.COM watchers out there?  Is this the right bug ID?  Is there a
fix?  What gives?

Tony Rick
Tektronix, Inc.  Beaverton, OR
Internet: tonyr@tekadg.adg.tek.com
Voice: 503-627-2942