[net.news.b] 'Cannot install' during expire

bllklly@uwmacc.UUCP (Bill Kelly) (10/24/84)

We've had some trouble with expire interfering with inews
for incoming news from our uucp feed.  Expire runs at 12:20
a.m., and sometimes overlaps with incoming news at 1:00.
The news log file will indicate Cannot install article as blah,
the error being that the article file already exists.  The
offending article file (the one that exists, but shouldn't)
was created while both inews & expire were running, but didn't
make it into the history file.  Not suprising, I guess, since
expire is rewriting the history.

So is there are recommended way of keeping expire and inews
from interfering?  I couldn't find anything in the code to
lock out incoming news or anything like that.  Should this
be a problem?  I'm going to fake a uucp lock while expire
is running if no one else has a better idea.
-- 

Bill Kelly
{allegra, ihnp4, seismo}!uwvax!uwmacc!bllklly
1210 West Dayton St/U Wisconsin Madison/Mad WI 53706

"Life's like a jigsaw...you get the straight bits, but there's plenty
 missing in the middle." -- Xtc

davest@daemon.UUCP (Dave Stewart) (11/01/84)

In article <413@uwmacc.UUCP> bllklly@uwmacc writes:
>We've had some trouble with expire interfering with inews
>...  Not suprising, I guess, since
>expire is rewriting the history.
>
>So is there are recommended way of keeping expire and inews
>from interfering?  

	Not only is expire mucking with the history file, but it's
also rebuilding the active file.  In either case, determinancy is lost
since these are asynchronous processes writing to the same location.
This is indeed a problem and one that should be looked at.  One solution
would be to put the same locking code that is in inews into expire.  Or
one might try some independant locking mechanism, such as uucp uses.
A solution I like is for the processes to put an exclusive lock on
the inode for the active and/or history files, such as the flock()
system call in 4.2BSD.  I realize that not everyone runs 4.2, but a
kernel-level advisory locking scheme is something that all versions of
Unix need for situations just like this.  (Just stick to the facts, sir)
Sorry!  I got carried away ...
-- 
David C. Stewart                          uucp:    tektronix!davest
Small Systems Support Group                        tektronix!usenet
Tektronix, Inc.                           phone:   (503) 627-5418