Path: utzoo!attcan!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.unix.xenix Subject: Re: uucico problem (XCLUDE); also, 2.2 vs 2.3. Message-ID: <1989Mar18.233136.14960@ateng.ateng.com> Date: 19 Mar 89 04:31:36 GMT References: <715@vector.UUCP> Organization: A T Engineering, Tampa, FL Lines: 33 According to chip@vector.UUCP (Chip Rosenthal): >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. Yup. The SVID exlicitly states that the XCLUDE flag remains in effect even when a devices is closed. My reading of the SVID didn't give me any indication that a fixup was possible, even as root. I think it depends on the type of serial line you use. We were using Computone (now Intelliport) serial boards, which have drivers which are eccentric at best. >I guess the better solution is to get 2.3 running. A hearty "amen" to that. Ever since I started using 2.3, I've been pleasantly surprised at its smarts. Except, of course, for the modes of /usr/spool/uucp being 777. Sigh. A nice feature: getty looks in the /usr/lib/uucp/Devices file and automatically sends the connection-is-done-now string to the device before printing the prompt. Thus if uucico died, the port still gets fixed up. Also, getty creates lock files for devices that UUCP knows about, but not for the rest (i.e. console ttys). Hint: After changing /usr/lib/uucp/Devices, disable and re-enable all ports involved in the change. Otherwise, the getty(s) in question won't know what's going on. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."