Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!nike!ll-xn!adelie!axiom!linus!philabs!rdin!perl
From: perl@rdin.UUCP (Robert Perlberg)
Newsgroups: net.bugs.uucp
Subject: Re: uucico/uuxqt bugs...howcome?
Message-ID: <579@rdin.UUCP>
Date: Thu, 25-Sep-86 13:47:53 EDT
Article-I.D.: rdin.579
Posted: Thu Sep 25 13:47:53 1986
Date-Received: Tue, 30-Sep-86 13:39:49 EDT
References: <900@gilbbs.UUCP> <612@pyramid.UUCP> <728@ncc.UUCP>
Organization: Resource Dynamics Inc., New York
Lines: 24

I have been using the following method on my machines (ONYX C8002M and
MASSCOMP MC500) for years now with great success:

Every hour, cron runs a program I call lckcheck.

lckcheck searches for LCK. files in /usr/spool/uucp.  For each LCK.
file, it opens the file and reads the PID from it.  It checks the
existence of the process that created the LCK. file by sending a signal
#0 with kill(2).  If the process does not exist, the file is removed.
If the process does exist, the file is touched.  This program is also
useful for when you suspect that a LCK.  file might be associated with
a dead process, but you don't want to remove it just in case it isn't.
I also use it to provide getty(8) with a way of creating LCK. files.
Since getty is never around when the shell process dies to remove the
LCK. file it created before exec'ing the shell, the next getty uses the
lckcheck technique to verify the validity of the LCK. file.  I don't
know why all programs that use LCK. files don't do this.  Why do
programs that don't use the PID for verification put the PID there in
the first place?

Robert Perlberg
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl