Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ski.UUCP
Path: utzoo!linus!decvax!tektronix!hplabs!hpda!fortune!amdcad!amd!dual!ptsfa!politik!ski!bks
From: bks@ski.UUCP ( Bruce K. Smith)
Newsgroups: net.bugs.uucp
Subject: Re: hung line help needed (workaround for Masscomp MC-500 site)
Message-ID: <141@ski.UUCP>
Date: Tue, 20-Nov-84 01:31:35 EST
Article-I.D.: ski.141
Posted: Tue Nov 20 01:31:35 1984
Date-Received: Fri, 23-Nov-84 02:35:44 EST
References: <449@godot.UUCP> <489@astrovax.UUCP>
Distribution: net
Organization: Smith-Kettlewell Institute, S.F., CA.
Lines: 65

> > 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?
> > -- 
> > --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
> 
> I am having this problem too.  I would sure as heck like to know what is
> going on.  The hanging seems to occur when the load average is high.  I
> believe that I installed a posted bug fix to alarm() and it didn't cure the
> problem.
> -- 
> Bill Sebok			Princeton University, Astrophysics
> {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls

We're running a Masscomp MC-530 with their RTU 2.1C ("Real Time Unix", some
combination of System III and 4.2BSD, I think). Our uucico's hang if and only
if there is no outgoing work for them (ie iff they never enter MASTER mode),
which can only happen when it's an incoming call. To work around the problem,
we had to arrange to mail a dummy message to a fake user on our sole uucp
neighbor. We did it by moving /usr/lib/uucp/uucico to .../uucico.actual,
and replacing .../uucico with a shell script which reads as follows:
==========================================================================
#!/bin/sh
# by Bruce K. Smith and Jordan K. Hubbard, ski!{bks,jkh}, 24 October 1984
# incoming calls: if no outgoing uucico work, mail a dummy message to work
#	around uucico.actual's hangup bug
# outgoing calls: use the "use" script to avoid stomping on anyone logged in on
#	tty2 or using another init state
# then call uucico.actual, the original version of uucico

# for security:
PATH=/bin:/usr/bin:/usr/local/bin

if test $# -eq 0
then
	# incoming call
	echo `date`: $0 >> /tmp/uulog
	outs=`echo /usr/spool/uucp/C* /usr/spool/uucp/D*`
	if test "$outs" = "/usr/spool/uucp/C* /usr/spool/uucp/D*"
	then
		mail politik!none < /usr/lib/uucp/dummy.msg
	fi
	/usr/lib/uucp/uucico.actual
else
	# outgoing call, try to grab tty2
	echo outgoing at `date`: $* >> /tmp/uulog
	use tty2 -u uucp /usr/lib/uucp/uucico.actual $*
fi
==========================================================================
The lines with C* and D* are for mailing the message only when there is no
work waiting to go out. If your system can be called by more than one other
system, you'll probably have to make this section more intelligent, or else
just send the message out all the time.
   The "outgoing call" stuff is for an unrelated problem.
   I have no idea whether this workaround works on systems other than the
Masscomp.

-- 
	Bruce Smith
	{sun!texsun, ucbvax!mtxinu, dual!ptsfa} !politik!ski!bks