Xref: utzoo news.software.b:7367 news.software.nntp:1241
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!world!geoff
From: geoff@world.std.com (Geoff Collyer)
Newsgroups: news.software.b,news.software.nntp
Subject: Re: nntp files
Message-ID: <1991Apr4.210714.13027@world.std.com>
Date: 4 Apr 91 21:07:14 GMT
References: <1991Mar31.214919.17956@ssd.kodak.com> <1991Apr3.213558.1035@cobber.cord.edu>
Distribution: na
Organization: The World @ Software Tool & Die
Lines: 28

Glen Overby:
>I had a similar problem here, and I found that I also had an nntpd processes
>to accompany each of the files!  Apparently nntpd wasn't exiting when the
>session ended.  I usually noticed this after I'd get a dozen or so NNTPDs
>hanging around apparently using a little CPU time here and there.

nntpd needs to be made smarter about impolite, anti-social (one is
tempted say ``obnoxious'') NNTP transmitters that keep an idle connection
open just in case an article might arrive eventually (e.g. nntplink).
Work is in progress on such an nntpd; no promises about when or how it
will be available.

In the meantime, you could try asking your NNTP neighbours to drop
connections when they have nothing to send (and to not connect just
because they have 0001 articles for you), if possible (I believe even
nntplink can be configured to be polite). 

>The problem magically went away when I recompiled WITHOUT CNEWS Batching
>(I'm running nntp 1.5.11 of course) so now I'm back to using newsspool for
>every incoming article. YUK!

You are taking quite a performance hit by having nntpd start a new rnews
process (especially on a Sun with its slow forks and execs) for each
incoming article.  It really would be much better to ask your neighbours
to be polite (i.e. say ``nice doggy'' until such time as we can find a
rock).
-- 
Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff