Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84 (WLS Mods); site astrovax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!wls
From: wls@astrovax.UUCP (William L. Sebok)
Newsgroups: net.bugs.uucp
Subject: Re: hung line help needed
Message-ID: <494@astrovax.UUCP>
Date: Sat, 17-Nov-84 15:45:15 EST
Article-I.D.: astrovax.494
Posted: Sat Nov 17 15:45:15 1984
Date-Received: Sun, 18-Nov-84 04:28:04 EST
References: <449@godot.UUCP> <85@daemon.UUCP>
Organization: Princeton Univ. Astrophysics
Lines: 28

In article <449@godot.UUCP> bruce@godot.UUCP (Bruce Nemnich) writes:

>>I have been having an awful lot of problems with hung lines with 4.2bsd
>>uucp.  By hung, I mean a uucp process sitting blocking on a read from
>>the dialout line, but having removed the LCKfile for that line and
>>system (presumably after a timeout).  The offending processes must be
>>killed by hand.  I breifly looked at the code, but I didn't notice
>>anything too bad.  The stack frame at the hung point is often
>>main()/conn()/login()/expect()/read(), though sometimes
>>main()/imsg()/read().  Any quick fixes?

And in <85@daemon.UUCP> (<--huh?) Russ Gorby (tektronix!russg) responds:

> We had that problem here at tektronix also. It only happens when the
> uucico session was initiated in answer mode, and the answering modem
> is connected to a data switch. ...

We have that problem at astrovax also but 1) we have no data switch, and 2) it
only occurs when dialing out, not in answer mode.  The problem has occured both
when the dialing modem is a Hayes and when the dialing modem is a Racal/Vadic
3451.

Actually, there is one difference in the symptom here.  The lockfile is still
there when it is hung. The hang point on the latest hang was
main()/conn()/Acuopn()/vadopn()/expect()/read().
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls