mark (02/19/83)
I see this kind of behavior often also, exactly as Randy describes it. I can add a little light: I suspect that uucico opened the first ACU for exclusive access and forgot to close it. I've even seen this happen when a uuxqt is the only trace of the original uucico. I haven't been able to track down the (presumably) missing close, but I haven't tried very hard. If someone finds (yet another) missing close, please tell us about it!
stevenm (02/20/83)
Here are the bugs that I have in the Bug List which concern that problem:
#############
# 9 #
#############
9) Connection Failure Leaves Line Open, Locked
From: teklabs!harpo!floyd!cmcl2!salkind
Date: Mon Mar 22 16:53:06 1982
Subject: uucp bug
Newsgroups: net.bugs.4bsd,net.bugs.v7
References: conn.c
In conn.c, if you fail to login to a machine, the (dialout) line file
descriptor will not be closed. Therefore the next open on the line will
fail (because the line is set for exclusive access).
This problem can show up if you execute (not as root)
uucico -r1
The fix is a one line addition to the routine login():
*** conn.c Mon Mar 22 16:25:50 1982
--- conn.c.old Mon Mar 22 16:27:42 1982
***************
*** 531,537
break;
if (altern == NULL) {
logent("LOGIN", "FAILED");
- close(fn);
return(FAIL);
}
want = index(altern, '-');
--- 531,536 -----
break;
if (altern == NULL) {
logent("LOGIN", "FAILED");
return(FAIL);
}
want = index(altern, '-');
________
Lou Salkind
cmcl2!salkind
############
# 14 #
############
14) Calling Multiple Numbers doesn't work
From: teklabs!ucbvax!mhtsa!alice!physics!gill
Date: Tue Jul 13 21:30:29 1982
Subject: Two bug fixes to uucico (and some 4.1 commentary)
Newsgroups: net.unix-wizards
References: anlwrk.c,anlwrk(),conn.c,dialup()
On another front, I have repaired a bug with dialup() in conn.c.
The multiple calling of multiple phone numbers during a single attempt by
uucico to contact a system didn't work.
This was because the alarm call which interrupted the "waiting for
carrier" open of the dz data line left the DTR bit high. Our DN dialer
refused to dial again on this line, since it thought it was busy. The only
way to lower DTR was for uucico to exit, since there was no file
descriptor to do a close on (open never returned). Luckily, as
there was a tty structure associated with that dz line, the exiting
of uucico caused a call to dzclose, lowering DTR.
I kludged up a solution by creating a child process which probed the DZ
line with its own timeout, and either sent a signal to uucico or died,
depending on whether or not open returned in time. Upon
receit of the signal, uucico opened the line for itself and killed the
child. If the wait returned instead, uucico just went on to try again;
the exiting of the child (the only one trying to open the dz line) caused
DTR to go low.
If anyone has had this problem and dreamed up a better solution, please
let me know. BTL UNIX 3.0 and beyond have no-wait opens, which offer a
much cleaner way of dealing with ACUs and their associated serial lines.
If there aren't any better ways around this in 4.1, I'll be happy
to send my version of dialup() to anyone interested. I've thought
of changing the 4.1 kernal to call dzclose when the open call is
aborted, but have decided that this wouldn't always be the right
thing to do.
Gill Pratt
reachable by mail at
....!alice!researc!physics!gill
or
gill@mc
From: teklabs!ucbvax!mhtsa!alice!physics!gill
Date: Fri Jul 16 12:26:01 1982
Subject: Another way to do multiple trys at dialing in uucico
Newsgroups: net.unix-wizards
Another way to lower DTR on interrupted open calls to DZ lines is
to close the file descriptor UNIX associates with the uncompleted
open. Since the aborted open returned -1, the only way to find
out what this file descritor was is to predict it beforehand.
A simple program illustrates the hack:
#include <signal.h>
catch()
{
}
main()
{
int fd,phantom;
printf ("Next fd = %d\n",phantom = nextfd());
signal (SIGALRM,catch);
alarm (2);
printf ("Open on cul1 returned %d.\n",open ("/dev/cul1",2));
#ifdef KLUDGE
close (phantom);
#endif
printf ("Next fd = %d\n",phantom = nextfd());
pause();
}
nextfd() /* Return the number of the next file desciptor assuming no
closes happen until the next open */
{
int phantom;
close (phantom = open("/dev/null",0));
return (phantom);
}
If KLUDGE is defined, then you get the same file descriptor both
before and after the aborted open (which returns -1). DTR
is lowered by the close(phantom). If KLUDGE is undefined, you
get two sequential descriptors, and the DTR lead isn't lowered until you
stop the process (i.e. let the system do the close).
Well, this is conceptually simpler than my fix, which involved forking
off an open prober, but it really violates the abstraction of file
descriptors being numbers passed to and returned by system calls.
It's the close/dup assumption taken to the extreme. If the ordinary UNIX
interface is call/return by value, the use of a predicted file descriptor
which you can't even verify (as you can with dup) is "call/return by
intuition." Yuch.
Thanx to Peter Honeyman for pointing this alternative out (it's
actually the method used by the research folks in their dialout() routine).
Gill Pratt
...alice!rabbit!physics!gill
or
...gill@mc