Xref: utzoo comp.lang.perl:5697 comp.unix.questions:32138 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!cherokee!newsat!jbw From: jbw@maverick.uswest.com (Joe Wells) Newsgroups: comp.lang.perl,comp.unix.questions Subject: Re: Chat2.pl and pty probs on a SparcII Message-ID: Date: 13 Jun 91 23:04:23 GMT References: <1991Jun13.062350.4067@colorado.edu> Sender: news@cherokee.uswest.com (Telegraph Row) Organization: /home/zeb1/jbw/.organization Lines: 27 In-Reply-To: frechett@spot.Colorado.EDU's message of Thu, 13 Jun 1991 06: 23:50 GMT Nntp-Posting-Host: maverick.uswest.com In article <1991Jun13.062350.4067@colorado.edu> frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes: I am finally getting the hang of chat2.pl and doing some fun little stuff and after much frustrating banging, thinking that my code was messed up, I realized that it was the ptys that were hanging on the Sparc I am using, or to be more precise, it in the process of opening a pty it hangs. I shouldn't have been surprised when I found this out as I run 'screen' all the time and it also hangs. Ussually I go to open a new pty and it locks up.. so I kill that window and then try again, and after a few times, it might work. ... This is a POSIX problem, and SunOS is moving towards POSIX compatibility. We were getting a lot of hung rlogins because of this at cs.bu.edu. The most likely cause is this: The master side of the pty pair is not held open by any process, so the pty pair appears to be free. However, some process on the system has the slave side of the pty pair as its controlling terminal. (I think the process also has to be a session leader, but I don't remember.) Due to POSIX semantics that I don't understand at all, this causes the open of the slave side to hang. Find the process that has that pty pair as its controlling terminal (easily determinable with ps) and kill it ruthlessly. The guilty process will be a process that should have *no* controlling terminal (eg. started by rsh). -- Enjoy, Joe Wells