Xref: utzoo comp.unix.xenix:3409 comp.unix.microport:1619
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cs.utexas.edu!milano!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Buggy UUCP (was: Re: Bell Tech 386 SysVr3)
Message-ID: <8349@bigtex.uucp>
Date: 23 Sep 88 03:13:09 GMT
References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <936@cerebus.UUCP> <7013@icdi10.uucp> <12017@steinmetz.g <385@pigs.UUCP> <394@marob.MASA.COM> <193@dcs.UUCP> <641@quando.UUCP>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Organization: F.B.N. Software, Austin TX
Lines: 27

In article <641@quando.UUCP>, biburger@quando.UUCP (Wolf-D. Biburger) wrote:

> I don't think so - there are instructions inside the programs, to
> check the existance of the 'LCK..'-file, but not any contents of it.

No.

> those 'LCK..'-files work as a semaphor (see the name....) and
> if they exist a long time there may get up a 'uuclean'-process,

Not correct on modern UUCPs (perhaps true for old ones though).

The contents of the LCK.. file are significant.  In HDB uucp the
contents correspond to the printf control string "%10d\n" and the
content id the PID of the locking process.  Other processes use the
content to determine if the lock is valid by using kill(PID, 0) and
checking for an error.  Therefore, invalid contents of the lock file
will cause an invalid PID to be read, which will prevent the locking
process from being found by kill(), and uucico will remove the lock.

Older UUCPs did not use the (relatively new) capability of kill to
detect the existence of a process, and hence simply assumed that a
lock was "stale" if it was old enough.  "Old enough" often meant an
hour or two.  This scheme doesn't terribly well.
-- 
James R. Van Artsdalen	...!uunet!utastro!bigtex!james	"Live Free or Die"
Phone: 512-346-2444		  10926 Jollyville Rd #901 Austin TX 78759