[comp.unix.xenix] uucico problem -- is XCLUDE really supposed to work this way?

chip@vector.UUCP (Chip Rosenthal) (03/11/89)

Here is a problem I ran into with uucico.  Following is a description of
the problem and what I found to be the cause.  At the bottom is a question
about the observed behaviour.  Any insights would be appreciated.

Configuration -- SCO XENIX 2.2.3 on an 80386

Symptoms -- after "uucico" aborts, all further accesses of the tty line
fail.  Subsequent uucico's note "line in use" as the error.

Analysis -- uucico apparently sets the XCLUDE flag on the line.  When
uucico aborts, it apparently performs no cleanups.  The LCK files are
left, getty is left suspended, and the line is left with XCLUDE set.
Subsequent attempts to open the line die with the "line in use" error
due to the XCLUDE flag.

Workaround -- the following hack _run_as_root_ unstuck the line:

	#include <stdio.h>
	#include <fcntl.h>
	#include <termio.h>

	main(argc,argv)
	int argc;
	char *argv[];
	{
	    int fd;
	    struct termio tty;
	    fd = open("/dev/tty2a",O_RDONLY);
	    ioctl(fd,TCGETA,&tty);
	    tty.c_lflag &= ~XCLUDE;
	    ioctl(fd,TCSETA,&tty);
	    exit(0);
	}

Question -- Is this reasonable??  When a line is closed shouldn't the
XCLUDE flag also be reset.  The only application I can see of this is
that a process can lock out a line without having to stick around.  I
think this is bogus.  If you want to do that -- use the standard
permissions.  That's what they are there for.

Bitch -- My uucico f*ckup-fixer script is getting really out of hand.
It already deals with orphaned lock files and suspended getty's on unused
lines.  I guess I will add the XCLUDE fix to it as well.  Unfortunately,
stty(C) doesn't understand the "xclude" flag.  I guess the better solution
is to get 2.3 running.
-- 
Chip Rosenthal     chip@vector.UUCP    |      Choke me in the shallow water
Dallas Semiconductor   214-450-5337    |         before I get too deep.

skrenta@blekko.home.nwu.edu (Rich Skrenta) (03/12/89)

Disclaimer first:

      I know nothing about the XCLUDE flag.  I'm also using Xenix 286 2.2.1.

When you say "uucico aborts" do you mean abnormally, or every time?
I had a problem that if uucico died for some reason (typically "bad baud rate"
when my Hayes compatible modems fell from 2400 to 1200) it would give the
symptoms you describe--modem hung, getty still suspended, the works.  Since
the getty is still suspended, further attempts to ungetty it result in
"line in use".

I found that the culprit was the dial programs that SCO provides.  Fortunately,
we have source to those.  I took me nearly three hours of hacking to figure
out how they work, but I was able to patch them NEVER to leave a line hosed.
I also increased the delay time between commands sent so I could change my
modem from &D2 to &D3--reinitialize to start up values every time DTR goes
low.  (My anchor modem resets very quickly, but my Maxum takes more than
a second, and the dial program was croaking on it).

If this fix sounds like it would help you out, I'd be happy to mail you
my modified dialHA24.c  I'm hesitant to send off a diff because our Xenix
versions are different.  If enough people want it, I suppose I could post it.

Rich

-- 
Rich Skrenta                 skrenta@blekko.home.nwu.edu
skrenta@eecs.nwu.edu         ...nucsrl!blekko!skrenta