erict@flatline.UUCP (j eric townsend) (12/10/88)
There is a rather sizable chunk of files in my $SPOOL/.rnews directory, some with dates as far back as two weeks ago. Questions: 1. Why are they there? 2. Should I run them them through rnews? (IE: they are there because rnews crashed out and didn't finish the file?) 3. Is this (wild files in .rnews) a regualar occurance? If so, why? thx. -- 'That's why our house has clay mirrors / So that I won't see my eyes in the morning.' -- Aquarium (an underground Russian band) J. Eric Townsend -- smail: 511 Parker #2, Houston, Tx, 77007 UUCP: uunet!sugar!flatline!erict ..!bellcore!texbell!/
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/13/88)
[Nobody has answered this yet?]
erict@flatline.UUCP (j eric townsend) writes:
There is a rather sizable chunk of files in my $SPOOL/.rnews directory,
some with dates as far back as two weeks ago.
1. Why are they there?
2. Should I run them them through rnews? (IE: they are there because
rnews crashed out and didn't finish the file?)
3. Is this (wild files in .rnews) a regualar occurance? If so, why?
1. When rnews attempts to unbatch a new incoming blortful of news,
and notices that expire(8) has locked the active file, it ships the
blortful off to $SPOOL/.rnews/<date/time>, in the (perhaps naive)
belief that expire will force rnews to get around to it later - keep
reading.
2. Yes (and probably). They should be run through rnews; this is
normally a part of expire's completion. After expire finishes the job
of building a new history file and getting rid of all those defunct
articles, it then exec(2)s "rnews -U," where -U is the unspool option,
specifically for flogging those <date/time> batches in .rnews. It
creates the file $SPOOL/.rnews.lock to identify the fact that an rnews
-U is in-progress. When rnews -U finishes, it is supposed to remove
.rnews.lock.
3. No. It would seem that rnews departed your system's world before
completion, and left the .rnews.lock lying around. Remove it by hand,
and make sure that your system runs rnews -U every now and then (i.e.,
hourly). Thus, expire will run rnews -U when finishing expiry, and it
will be executed now and then as a general precaution. But rnews -U
won't unspool if it already finds the .rnews.lock file; hence expire's
attempts to do so have been futile for (as you say) as long as 2 weeks.
I think I got it all right there. Did I miss any details, folks?
--Karl