Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry F Aguirre)
Newsgroups: comp.unix.questions,news.sysadmin
Subject: Re: uuxqt problems with news
Message-ID: <1407@oliveb.UUCP>
Date: Mon, 15-Jun-87 14:12:56 EDT
Article-I.D.: oliveb.1407
Posted: Mon Jun 15 14:12:56 1987
Date-Received: Sun, 21-Jun-87 02:09:29 EDT
References: <116@bvax.UUCP> <311@pollux.UUCP> <748@van-bc.UUCP> <287@l5comp.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Distribution: na
Organization: Olivetti ATC; Cupertino, Ca
Lines: 32
Keywords: news, UniStride 2.1, HELP!
Xref: mnetor comp.unix.questions:2845 news.sysadmin:229

Even with "spooling" turned on you may still have lengthy overhead at
uuxqt time.  If the transmitting site is sending you news in "cunbatch"
format rather than "#!cunbatch" format then the "uncompress", which is a
large part of the overhead, will happen at uuxqt time.  The rnews
invoked will save the article for later processing but the uncompress
overhead will slow things down.  If the timeout on the uuxqt lock file
expires then you will get another "cunbatch" will happen with another
uncompress running in parallel.

Older versions of news (2.10) execute the "cunbatch" command instead of
"rnews".  Newer versions (2.11) will use this format if the "-o" option
of "sendbatch" is used.  Frequently this is used when the new site is
feeding a site requiring the old version.

The preferable sollution is for the site feeding you to switch to the
new format.  (Remove the "-o" option to "sendbatch".).  If they are
queueing a single batch for multiple sites and some of them are old
versions then this may be a problem.  If your feed is itself running
an old version then urge them to upgrade.

The second alternative is to replace "cunbatch" with something that just
saves the "cunbatch" for later processing.  Several shell scripts have
been posted in the past.  I have some C programs that I use here but
they are somewhat BSD dependant.  The uncompression, unbatching, and
rnews processing is done only when the load is below a specified level.

As far as the rnews/expire timing problem goes, wouldn't it make more
sense to run expire BEFORE polling for new news?  If you ran expire at
midnight, and then polled at 2AM then you would have less chance of an
overlap.  After all, you control the expire, you can only make a try for
the uucp.  This also makes more sense if you think of the expire
clearing out disk space for the news that is about to arrive.