chip@ateng.ateng.com (Chip Salzenberg) (03/19/89)
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 <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@vector.UUCP (Chip Rosenthal) (03/20/89)
chip@ateng.ateng.com (Chip Salzenberg) writes: >According to chip@vector.UUCP (Chip Rosenthal): >>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. Luckily, on SCO 2.2 you can open("/dev/tty2A",O_RDONLY|O_NDELAY) as root and patch it up. I've been told that Tandy XENIX won't allow this; once XCLUDE is set that line is really locked. One has to wonder if this area of SVID was rationally developed or if it covers a kludge in the initial tty driver. >Except, of course, for the modes of /usr/spool/uucp being 777. Sigh. Does this have to be?? Are you saying: drwxrwx-wx 6 uucp uucp 4336 Mar 19 17:56 /usr/spool/uucp won't work? That's what I do now. P.S. Thanks for the info on Devices. -- Chip Rosenthal chip@vector.UUCP | -------- watch this space -------- Dallas Semiconductor 214-450-5337 | - real domain address coming soon -
chip@ateng.ateng.com (Chip Salzenberg) (04/06/89)
According to chip@vector.UUCP (Chip Rosenthal): >chip@ateng.ateng.com (Chip Salzenberg) writes: >>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. > >One has to wonder if this area of SVID was rationally developed or if >it covers a kludge in the initial tty driver. Henry Spencer (?) jokes that SVID means System V Implementation Description. In the case of the XCLUDE kludge -- er, flag -- I entirely agree. >Are you saying: > > drwxrwx-wx 6 uucp uucp 4336 Mar 19 17:56 /usr/spool/uucp > >won't work? That's what I do now. It could eventually break unless you *never* run two simulaneous uucico's. The results could be that the directory is automagically changed to 777 again. There's a race condition in uucico. The sequence of events is: get old-modes of /usr/spool/uucp chmod 777 /usr/spool/uucp mkdir /usr/spool/uucp/systemname chmod old-modes /usr/spool/uucp This broken behavior is required because (1) the mkdir system call isn't used, since uucico was compiled with the Development System 2.2, and (2) System V's setuid behavior is *bizarre*, and it interacts oddly with the setuid bit on /bin/mkdir. *SIGH*. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."