Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request From: tonyr@tekadg.adg.tek.com (Tony Rick) Newsgroups: comp.sys.sun Subject: Re: Pty problem on sun4's under SunOs 4 Keywords: SunOS Message-ID: <5646@brazos.Rice.edu> Date: 9 Mar 90 21:10:59 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 59 Approved: Sun-Spots@rice.edu X-Refs: Original: v9n73 X-Sun-Spots-Digest: Volume 9, Issue 80, message 3 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 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