bytebug@fritz.UUCP (Roger L. Long) (12/25/86)
Patch #2 supposedly fixed inews.c so that if the news system is locked (as
is the case if expire is running), "rnews -U" wouldn't run to unbatch news.
Specifically, the lines that were added are:
if (spool_news) /* can't unspool while things are locked */
xxit(0);
However, this seems to break news unbatching completely. As far as I can
tell from reading the installation guide, when you have news being spooled,
you should insert (something like) the following line into your crontab:
10 * * * * /usr/bin/rnews -U
But after installing Patch #2, if you don't specify -S before the -U in your
invocation of rnews, spool_news will be set, and rnews will exit.
Thus, I would move the code looking for -S after the test for -U. Will this
break anything else?
The second problem which has been there and this patch doesn't change is the
case of multiple "rnews -U" running. If you get a lot of news, and the
system is loaded, and rnews is running niced, and if you have a line in your
crontab to run rnews once an hour, you may find that by the time an hour has
gone by, rnews is still running and another one is started. Although rnews
will now check if the news system is locked, it doesn't seem to lock the news
system itself. Is this true, and if so, is it desired to be this way for
some reason?
As I understand the code, the shared lock that inews puts on the news system
will keep expire from running, since expire requires an exclusive lock. And
if inews tries to do a (non-blocking) shared lock while expire is already
running, that will fail so news will be spooled. I suggest upgrading to an
exclusive lock in dounbatch(), to keep only one "rnews -U" running.
--
Roger L. Long
FileNet Corp
{hplabs,trwrb}!felix!bytebug