Path: utzoo!utgpu!cunews!micor!ecicrl!clewis
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.sys.3b1
Subject: Re: CONN FAILED (DEVICE LOCKED) - HDB
Message-ID: <2212@ecicrl.ocunix.on.ca>
Date: 21 Jun 91 17:12:40 GMT
References: <455.28605DC6@mcws.fidonet.org> <4474@jethro.Corp.Sun.COM>
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 23

In article <4474@jethro.Corp.Sun.COM> gak@gakbox.Corp.Sun.COM (Richard Stueven) writes:
>In article <455.28605DC6@mcws.fidonet.org>, BHeess@mcws.fidonet.org (Brian Heess) writes:

>|> uucp mcws  (6/19-23:24:52,99,0) CONN FAILED (DEVICE LOCKED)
>
>I've seen this happen a lot.  When an incoming call disconnects, often the
>lock file does not get removed.  I wrote a small program, "uuunlock.c", that
>validates the lock file(s) and removes them if they're invalid.  Since it's
>a short program, I'll include it here rather than posting to the source group.

Odd, my HDB UUCP does do a validate on the lock file.  If I kill -9
a uucico, the locks are left around.  Running a second UUCP with
debug on shows that it's found a lock file and that it's okay to
remove it.  I believe that HDB also does the kill 0 trick.

On the other hand, I'd be more interested in seeing if there was still
a process running.  Run uustat -p and see if there's a running uugetty
with a lock.
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!