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}
dave@lsuc.UUCP (06/09/87)
In article <762@bakerst.UUCP> kathy@bakerst.UUCP (Kathy Vincent) writes: >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 ... Don't you know the first rule of UNIX use? The only real documentation for anything is in the source code, not the manuals :-) And you have to be creative when grepping. Try grep "\.lock" inews.c (spbuf gets "+rnews.lock" or ".rnews.lock" depending on #ifdef VMS) Seriously, it would be very nice if Rick would provide patches to the documentation along with the patches to the source. The explanations which come with the patches are too fleeting. Rick, you've done a professional job of posting patches; can you follow it up with a patch for all the documentation, followed by future patches complete with doc patches? It would be appreciated. David Sherman The Law Society of Upper Canada -- { seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave