Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 11/03/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: <498@astrovax.UUCP>
Date: Wed, 21-Nov-84 01:54:36 EST
Article-I.D.: astrovax.498
Posted: Wed Nov 21 01:54:36 1984
Date-Received: Wed, 21-Nov-84 08:54:13 EST
References: <449@godot.UUCP> <85@daemon.UUCP> <492@godot.UUCP>
Distribution: net
Organization: Princeton Univ. Astrophysics
Lines: 39

In review: the subject is the hung uucico processes that we have here
at astrovax and godot.  This is when running rtiuucp under 4.2 BSD.
A typical hang point is main()/conn()/Acuopn()/vadopn()/expect()/read().
allegra has also reported such problems with honey danber under 4.2 BSD.

More information.

in cico.c the SIGALRM handler is

	timeout()
	{
		logent(Rmtname, "TIMEOUT");
		systat(Rmtname, SS_FAIL, "TIMEOUT");
		longjmp(Sjbuf, 1);
	}

while in pk1.c  the SIGALRM handler is

	cgalarm() { longjmp(Getjbuf, 1); }

However in condevs.c and conn.c the SIGALRM handler is:

	alarmtr()
	{
		signal(SIGALRM, alarmtr);
		if (next_fd >= 0) {
			if (close(next_fd))
				logent("FAIL", "ACU LINE CLOSE");
			next_fd = -1;
		}
		longjmp(Sjbuf, 1);
	}

I have never seen any hung processes when the first two handlers are
in effect, only when the last one is in effect.  Assuming its a race, I
don't know if it involves the signal() or the close().
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls