uucico problem -- is XCLUDE really supposed to work this way?

[Chip Rosenthal]

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 at vector.UUCP    |      Choke me in the shallow water
Dallas Semiconductor   214-450-5337    |         before I get too deep.