abrams@bnl.ARPA (Karl L. Abrams) (10/15/87)
I have finally gotten around to installing version 2.11 of news, and find that expire seems to be doing funny things to the history file. When an article is due to expire, it is removed from the spool, but its entry in history is only partially removed. For example, before expire: <1906@arthur.cs.purdue.edu> Sep 18 00:13 news.announce.newusers/63 <1907@arthur.cs.purdue.edu> Sep 18 00:13 news.misc/693 news.config/222 <1908@arthur.cs.purdue.edu> Sep 18 00:13 news.admin/799 news.announce.newusers/64 and after expire runs: <1906@arthur.cs.purdue.edu> Sep 18 00:13 <1907@arthur.cs.purdue.edu> Sep 18 00:13 <1908@arthur.cs.purdue.edu> Sep 18 00:13 All articles older than 14 days have this done to them, and the history file is growing longer every day. We are running Ultrix2.0 on a VAX780, and I know of another site, BSD 4.3, on which the same thing is happening. Has anyone encountered this problem? Thanks in advance..... -- ARPA: abrams@bnl.APRA BITNET: abrams@bnl.BITNET UUCP: ....philabs!sbcs!bnl!abrams
hyc@starbarlounge.cc.umich.edu (Howard Chu) (10/19/87)
In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes:
% I have finally gotten around to installing version 2.11 of news,
%and find that expire seems to be doing funny things to the history file.
%When an article is due to expire, it is removed from the spool, but its
%entry in history is only partially removed. For example, [omitted]
%...
%All articles older than 14 days have this done to them, and the history file
%is growing longer every day.
% We are running Ultrix2.0 on a VAX780, and I know of another site,
%BSD 4.3, on which the same thing is happening.
% Has anyone encountered this problem?
% Thanks in advance.....
%
%--
%ARPA: abrams@bnl.APRA
%BITNET: abrams@bnl.BITNET
%UUCP: ....philabs!sbcs!bnl!abrams
That's not exactly the normal behavior, but that's documented... You run
expire with the '-e xx' flag to delete articles after xx days, and with
'-E xx' to remove them from the history file after xx days. Of course, the
docs say that by default, articles will be removed from the history files
at the same time that they're deleted from the spool directory. That is,
usually you don't need to specify the -E option...wjt@wp3b01.UUCP (Bill Taggart) (10/20/87)
In article <37f435e1.d130@starbarlounge.cc.umich.edu> hyc@starbarlounge.cc.umich.edu (Howard Chu) writes: >In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes: >%When an article is due to expire, it is removed from the spool, but its >%entry in history is only partially removed. For example, [omitted] >%... > >That's not exactly the normal behavior, but that's documented... From scanning the defs.h code in the news2.11 source it is normal behavior. DFLTEXP sets 2 weeks as the default for expiring articles from the spool directories and HISTEXP sets 4 weeks to remove them from the history files. This ensures that old articles don't keep reappearing on your machine. You have a choice of either changing the defaults in the defs.h and recompiling or use the expire -e and -E options. -- Bill Taggart {uunet | ihnp4}!wp3b01!wjt
wtm@bunker.UUCP (Bill McGarry) (10/21/87)
In article <37f435e1.d130@starbarlounge.cc.umich.edu> hyc@starbarlounge.cc.umich.edu (Howard Chu) writes: >In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes: >% I have finally gotten around to installing version 2.11 of news, >%and find that expire seems to be doing funny things to the history file. >%When an article is due to expire, it is removed from the spool, but its >%entry in history is only partially removed. For example, [omitted] > >That's not exactly the normal behavior, but that's documented... [omitted] >the docs say that by default, articles will be removed from the history files >at the same time that they're deleted from the spool directory. Actually, it is normal behavior for 2.11 news for articles to remain in the history file after the articles have been expired. This is to prevent messages from re-appearing (due to multiple news feeds, etc). The default is to expire articles in 14 days and to keep the ID's in the history file for an additional 14 days. Bill McGarry Bunker Ramo, Shelton, CT PATH: {philabs, decvax, fortune, yale}!bunker!wtm
dave@lsuc.UUCP (David Sherman) (10/21/87)
This discussion prompted me to take a peek in our history file,
and I noticed a bunch of entries that should have been deleted
long ago. We expire with -n comp,misc,rec, etc., and I never
added "alt" to the list when alt started. I also discovered
we weren't having it delete "to", which gets the occasional test
posting.
So, if you're expiring with -n, make sure you're catching "alt",
as well as any local groups and other bits 'n' pieces.
David Sherman
The Law Society of Upper Canada
Toronto
--
{ uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave
Pronounce it ell-ess-you-see, please...spaf@uther.cs.purdue.edu (Gene Spafford) (10/22/87)
In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes: >[...] >When an article is due to expire, it is removed from the spool, but its >entry in history is only partially removed. For example, before expire: > ><1906@arthur.cs.purdue.edu> Sep 18 00:13 news.announce.newusers/63 ><1907@arthur.cs.purdue.edu> Sep 18 00:13 news.misc/693 news.config/222 >and after expire runs: ><1906@arthur.cs.purdue.edu> Sep 18 00:13 ><1907@arthur.cs.purdue.edu> Sep 18 00:13 > >All articles older than 14 days have this done to them, and the history file >is growing longer every day. This is *exactly* how news 2.11 is supposed to behave! There are basically 2 expirations going on with the history file. One is controlled by the DFLTEXP define in the defs.h file, and this defines how long before the article body remains on disk before it is deleted by expire. The normal expiration period is 2 weeks, although many sites set that higher or lower depending on local disk capacity. The second expiration limit is controlled by the HISTEXP define. This governs how long the information about an article (basically the article ID and time of arrival) remains in the history file. The distributed default on this is 4 weeks, and it should always be longer than the DFLTEXP value. If an article arrives at your site and the article ID is in the history file, the article is rejected (your site has already received it). If that information is not kept and a copy of the article reaches your machine after the expiration, the article would appear again at your machine (and your machine would again forward it to your neighbors). By keeping the information in the history file after the article has been expired from disk, it helps keep "time warps" from occurring and old articles from reappearing on your system. It also enables sites like arthur.cs.purdue.edu to have expiration periods of 4 days (due to very constrained disk space) and not end up getting articles multiple times due to normal Usenet propagation delays. After HISTEXP has passed, those entries will be deleted from your history file -- it will not grow boundlessly. Three asides on this: 1) Other, similar entries can appear in your history file -- in cases where you get a 'cancel" message before the actual article arrives, the ID is put in the history file to cause the article to be discarded when it does arrive. 2) using "expire -r" removes all the HISTEXP entries when it rebuilds the history file. As such, it should only be used if the history file gets totally trashed. The "expire -h" form ignores the history file when looking for articles to expire, but preserves the HISTEXP information. I recommend using this once every 1 to 2 weeks. 3) The -e option to expire can be used to override the DFLTEXP value, and the -E option can be used to override the HISTEXP option. -- Gene Spafford Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
dan@maccs.UUCP (Dan Trottier) (10/23/87)
In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes: > > I have finally gotten around to installing version 2.11 of news, >and find that expire seems to be doing funny things to the history file. >When an article is due to expire, it is removed from the spool, but its >entry in history is only partially removed. For example, before expire: > ><1906@arthur.cs.purdue.edu> Sep 18 00:13 news.announce.newusers/63 ><1907@arthur.cs.purdue.edu> Sep 18 00:13 news.misc/693 news.config/222 ><1908@arthur.cs.purdue.edu> Sep 18 00:13 news.admin/799 news.announce.newusers/64 > >and after expire runs: > ><1906@arthur.cs.purdue.edu> Sep 18 00:13 ><1907@arthur.cs.purdue.edu> Sep 18 00:13 ><1908@arthur.cs.purdue.edu> Sep 18 00:13 > >All articles older than 14 days have this done to them, and the history file >is growing longer every day. > We are running Ultrix2.0 on a VAX780, and I know of another site, >BSD 4.3, on which the same thing is happening. I too have experienced this kind of problem among others. To remedie this situation we try to rebuild the history files each week with expire -r. I say try because the result of the rebuild is an error message saying that my active file is corrupt and the nhist* files are left lying around. As far as I can tell the nhist* files are ok! We often see messages such as "/comp/sys/ibm/pc/1234 does not exist" in the expire log file. After checking the file refered to by the message is indeed there and readable (to the world). The path given "/comp/..." seems strange, shouldn't it be "/usr/spool/news/comp/..."?!? We are running on a VAX 11/780 with 4.3bsd and news 2.11 patch level 8 The big boys do seem to helpfull on this one and who can blame them. I think this is an obvious configuration problem but I'll be damned if I can track it down. If anyone out there has any ideas I sure would like to hear them. -- Dan Trottier | ...!uunet!mnetor!maccs!dan DCSS, McMaster University | ...!utzoo!lsuc!maccs!dan Hamilton Ontario Canada | dan@mcmaster.BITNET L8S-4K1 | Tel: (416) 525-9140 ext:3444