Xref: utzoo comp.unix.xenix:3210 comp.unix.microport:1467
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!vector!chip
From: chip@vector.UUCP (Chip Rosenthal)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Buggy UUCP (was: Re: Bell Tech 386 SysVr3)
Message-ID: <538@vector.UUCP>
Date: 2 Sep 88 16:05:22 GMT
References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <936@cerebus.UUCP> <7013@icdi10.uucp> <12017@steinmetz.g
Reply-To: chip@vector.UUCP (Chip Rosenthal)
Organization: Dallas Semiconductor
Lines: 23

In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>>i am currently having trouble on three systems i administer with LCK..
>
>the problem occurs when non-uucp communications programs
>(such as Kermit, ProComm or `CU') placed the LCK.. files there.

Strange.  I've written my own comm program, and I've never seen this
problem.  Do these things create proper lock files, i.e. containing
the PID of the lock owner?

>older uucico programs. If the aforementioned foreign comm program
>has set a lock on tty1a, and uucico is started up on tty1A...

My solution has been to lock both tty1A and tty1a.  On the flip side,
it's a really good idea for a comm program to check /etc/utmp as well
as the lock files.  With dialin/dialout lines, you can step on a dialin
unless you first verify that the line is unused.


-- 
Chip Rosenthal     chip@vector.UUCP | I've been a wizard since my childhood.
Dallas Semiconductor   214-450-0486 | And I've earned some respect for my art.