kathy@bakerst.UUCP (06/08/87)
The Case of the Long-Ignored Incoming News
In our last episode, dear readers, we were stuck with a an
ever-increasing collection of incoming, spooled news in the
/usr/spool/news/.rnews directory - and an apparently
nonfunctioning and/or on_vacation rnews where there had
previously been a fully functioning, hard-working rnews
before.
After some Trials and Tribs and Great Frustration, I decided
the problem was related to expire. Reason: The source code
says rnews won't run if expire is running; and when I'd try
to run rnews, it would kick in, and then stop - as if it
woke up, saw expire running, and went back to bed.
But expire *wasn't* running full-time, of course. Was there
some reason why rnews *thought* expire was running when it
really wasn't?
I found the apparent reason today: a file in /usr/spool/news
called .rnews.lock and dated the Day News Died.
I grepped thru all the docs, man files, and code that I
have, and found no mention of such a file ... In fact, I even
grepped for just "lock" and turned up only a few references,
mostly to "block"s. Did I miss something? I have 2.11 docs
and man files, 2.11.8 source.
I'm still not sure what happened. I did expire/archive all
my news that day in preparation for backing up my 3B1. I
recall starting an expire and stopping it - but then running
expire to completion after that. Assuming I'm not
"disremembering" - which I don't think I am but anything is
possible - I'd've thought the second expire would have killed
any lock file left over from a previous incomplete expire -
if, in fact, that's where the .rnews.lock file came from.
Perhaps not. Any enlightenment out there?
There were also a couple of other .something files - sorry,
but I was so fixated on the .rnews.lock file that I don't
remember what they were. Anyway, the one problem is solved.
And I thought someone, somewhere else just might benefit from
the news about the .rnews.lock file.
I still haven't figured out why my 3B1 doesn't want to
process news incoming from my 3B2/300, but maybe there's
another subtle reason for that that'll turn up one of these
days.
Meanwhile, I caught all the incoming unix-pc news and reposted
it, so no one who's getting the unix-pc groups from me need
worry about having missed anything during the Time of Troubles.
Kathy Vincent kathy@bakerst.UUCP
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Home: {ihnp4|mtune|ptsfa} _____
{hplabs|seismo}!kitty _____\__ !bakerst!kathy
{burl|mcnc|duke}!ethos _____/
AT&T: ihnp4!wruxh!unix
{mtune|burl|ihnp4}!wrcola!{root|kathy}kathy@bakerst.UUCP (06/08/87)
In article <762@bakerst.UUCP>, kathy@bakerst.UUCP (Kathy Vincent) writes: > > I'd've thought the second expire would have killed > any lock file left over from a previous incomplete expire - > if, in fact, that's where the .rnews.lock file came from. Which it isn't. The .rnews.lock is apparently placed by rnews when *it* runs. As I just had a chance to verify. Kathy Vincent kathy@bakerst.UUCP :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: HOME: {ihnp4|mtune|ptsfa} _____ {hplabs|seismo}!kitty _____\__ !bakerst!kathy {burl|mcnc|duke}!ethos _____/ AT&T: ihnp4!wruxh!unix {mtune|burl|ihnp4}!wrcola!{root|kathy}