Newsgroups: news.software.b
Path: utzoo!utstat!news-server.csri.toronto.edu!utgpu!cunews!fts1!michael
From: michael@fts1.uucp (Michael Richardson)
Subject: Re: Cnews and old news
Message-ID: <1990Sep25.025244.27071@fts1.uucp>
Organization: Fountain Technical Services, Ottawa, ON
References: <26675@mimsy.umd.edu> <1990Sep23.042833.24834@zoo.toronto.edu>
Date: Tue, 25 Sep 90 02:52:44 GMT

In article <1990Sep23.042833.24834@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>on the fringes of Usenet, fairly long propagation delays are not unheard-of.)
>
>We had hoped that keeping more history, using dbz's more efficient history
>database, would be sufficient.  I think the answer is no.

  One problem that I've been having recently (news feeds have been changing
around at lot in Ottawa. At one point I was getting a near complete newsfeed
from two places, and passing it on --- UNBATCHTED. Woops.) is that the dbz
routines hit the ulimit (which seems to be set around 1.5meg for reasons that
I haven't quite figured out... Probably something to do newsrun getting started
from cron.) and start dying. 
  Since this is SVR3.2, I have to run setnewsids in front of relaynews, so
I stuck a 'ulimit(2,ulimit(1,1)*2);' in there and recompiled.
  I've also reduced the number of days of history that are kept. 
  It might be a good idea to stick some code into setnewsids to deal with
this situation. I personally would rather just have disk quotas...

  I haven't checked out cron to see what the ulimit is when it is run is.
  I'm going to try rebooting in case cron was stopped at some point and
then restarted manually for some reason (I'm not the only sysadmin here).

-- 
   :!mcr!:            |  'Golf sucks anyway --- give the land to the
   Michael Richardson |    Indians'  --- recent CANACHAT comment.
 Play: mcr@julie.UUCP Work: michael@fts1.UUCP Fido: 1:163/109.10 1:163/138
    Amiga----^     - Pay attention only to _MY_ opinions. -   ^--Amiga--^