Path: utzoo!utgpu!watserv1!maytag!xenitec!iguana!lsuc!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: news.software.b Subject: Re: Is C-News reliable? Its certainly faster... Message-ID: <1215@ecicrl.ocunix.on.ca> Date: 25 Jan 91 06:24:07 GMT References: <1991Jan24.014403.1255@coplex.uucp> Organization: Elegant Communications Inc., Ottawa, Canada Lines: 88 In article <1991Jan24.014403.1255@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes: > However, I am curious, do people generally regard C-News (as of the >Dec-15th patch) as being completely reliable for news transmission? It's completely reliable modulo a few caveats. See below... >But it concerns me >that there are so many shell scripts used instead of binaries. Scripts >are nice, but there are some things (ala postnews) that seem a little >too complex for script use. There's nothing unreliable about scripts per-se. No worse than compiled programs. Provided they're written well (and C-new's are). > Anyone had any problems with the scripts? Also, I like the methods >of checking free space, but I was curious how well recovery is taken >care of when space becomes too low (unbatching, etc). C-news is perfectly reliable as long as: 1) all of the throttles work, both incoming, spooling and news control areas. Test 'em. 2) the throttles are set "reasonably" 3) You don't routinely run close to the edge 4) You pay attention to what C-new's admin scripts tell you. Some suggestions: 1) If at all possible, get the news spool area OFF of the partition that has UUCP queues. Eg: /usr/spool/news and /usr/spool/uucp are different partitions. This decouples incoming throttles from outgoing ones, otherwise, the throttles can sometimes go into something that looks like positive feedback and your disk space goes up and down like a yoyo, or your incoming feed bogs down or starts tossing articles. You want to make sure that even if a big flood comes in, it doesn't bog down your outflow. If it does, you're screwed. 2) You should occasionally check to ensure that your spool areas are above the thresholds. Under certain circumstances, the incoming throttle can stall out the incoming feed indefinately. Which really can get you into trouble. 3) Write a cron script to kill incoming feed's uucico sessions and temporarily "Never" that site's Systems/L.sys entries, if the disk space falls below some threshold. This should be above the unpacking threshold. Maybe Jim Mercer at lsuc would publish "spoolfull" as a starting point. (I wrote much of it, but it is "his" machine) 4) If you're getting a high volume feed, you MUST keep up. Otherwise, your feed will start expiring articles before they're batched to you, and you'll never catch up again. (without intervention). About a week ago I unstuck one system that was over a week behind. Needed several expires (that almost rm -fr's). Never saw so many news articles go thru so fast in my life... 5) Running expire more than once per day is often good if you have high thru-put but short retention times. You want news flowing as much as possible. 6) outgoing stuff: keep the queue sizes *down*, but at the same time, up the sendbatch call times to a point where if a site has fallen behind, if it connects, sendbatch will be called frequently enough to keep the line busy until everything's sent. This is a compromise, because sendbatch can sometimes be a real hog. The one thing stock C news can't do is stop other sites from giving you batches. If you hit the unpacking threshold, news articles will stay on your machine for longer than they should (they don't get unpacked to be candidates for outgoing or expiry) and you'll probably start tossing batches. As mentioned in (3) there are programs to solve this. There are other tools available, such as rnews.c which I believe can do progressive expires if you're short of space, and have faster (but less portable) ways of doing spacefor. There are other tools to treat other partitions on your disk as "shock absorbers" for incoming stuff. As long as you stay away from the thresholds, you shouldn't need these things. Bnews, on the other hand, is a little less sophisticated in some of the throttles. Bnews, particularly older ones, had a tendency to fill disks, then expire would clear some space, and Bnews would stagger on. Possibly with corrupt history files and lost articles which you don't get to know about. The latest version (PL19) is pretty good. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff enquiries: psroff-request@eci386, current patchlevel is *7*.