don@grc.UUCP (Donald D. Woelz) (12/15/87)
I am still having problems with my expire command and have not received
any response or help from my previous posting.
When I run expire from a shell script late every night, nothing gets
expired. If I run it manually, I get the same results.
If I run expire -hir (I know it looks redundant), I get
the following message:
expire: Cannot open ///usr/lib/news/history (r): No such file or directory
I have the history.d and history.od directories and their appropriate
contents in the correct place. Why is it looking for a history file?
If I create an empty history file, it expires okay using the above
expire command, but there is no history file left when it is done. Only
the history.d and history.od directories and their contents.
What is happening here?
FYI, I am running System V Release 2 on an NSC 32032 based CPU on the Qbus.
--
Don Woelz {ames, rutgers, harvard}!uwvax!uwmcsd1!grc!don
GENROCO, Inc. Phone: 414-644-8700
205 Kettle Moraine Drive North Fax: 414-644-6667
Slinger, WI 53086 Telex: 6717062jack@csccat.UUCP (Jack Hudler) (12/18/87)
First of all you did not state what patchlevel you are running, but I will assume that it's less than 12. Patch 12 or 13 fixed that problem. Jack@csccat -- See above (214)661-8960
jay@splut.UUCP (Jay Maynard) (12/24/87)
In article <782@grc.UUCP>, don@grc.UUCP (Donald D. Woelz) writes: > expire: Cannot open ///usr/lib/news/history (r): No such file or directory > > I have the history.d and history.od directories and their appropriate > contents in the correct place. Why is it looking for a history file? > If I create an empty history file, it expires okay using the above > expire command, but there is no history file left when it is done. Only > the history.d and history.od directories and their contents. I am having the same problem (expire doesn't, and prints the same error message, minus two of the three leading slashes). I'm running patchlevel 12 on Microport System V/AT. Anyone got any solutions? Even as simple as "run patchlevel 14"? -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. The opinions herein are shared by none of my cats, much less anyone else.
don@grc.UUCP (Donald D. Woelz) (03/08/88)
I have a problem with expiring my news. Well, maybe even two problems.
First off, I am running on System V Release 2 on an NSC32032 based
machine. When I run expire, it sends back a message saying that it
cannot open the history file. I was under the impression that I did
not require the history file as the history information was kept in
the history.d directory. Why is this thing looking for a history file?
I can make it work if I first create an empty history file and then
using expire -e10 -hIr to expire the news. Any constructive comments
would be appreciated.
Second problem...the maps! I do not have enough room on my machine
to keep the maps as articles. We use uuhosts and pathalias to update
the working version of the maps weekly. I realize that the new
distribution method for the maps requires longer expiration times, but
I cannot seem to expire these maps at all before the expiration date.
What do I need to do to expire them?
--
Don Woelz {ames, rutgers, harvard}!uwvax!uwmcsd1!grc!don
GENROCO, Inc. Phone: 414-644-8700
205 Kettle Moraine Drive North Fax: 414-644-6667
Slinger, WI 53086 Telex: 6717062rsalz@bbn.com (Rich Salz) (03/11/88)
In news.software.b (<816@grc.UUCP>), don@grc.UUCP (Donald D. Woelz) writes: >... I do not have enough room on my machine >to keep the maps as articles. We use uuhosts and pathalias to update >the working version of the maps weekly. I realize that the new >distribution method for the maps requires longer expiration times, but >I cannot seem to expire these maps at all before the expiration date. If you use UUHOSTS to unpack the maps directory, then you don't need the maps in your spool directory at all. Get rid of them however you like, I.e., uuhosts -unbatch for I in /usr/spool/news/comp/mail/maps/* ; do > $I done Or check out the -I flag. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/12/88)
In article <816@grc.UUCP> don@grc.UUCP (Donald D. Woelz) writes:
:Second problem...the maps! I do not have enough room on my machine
:to keep the maps as articles. We use uuhosts and pathalias to update
: ... I cannot seem to expire these maps at all before the expiration date.
The nicer way is to occasionally run "expire -I -e3 -n comp.mail.maps"
(-e3 says 3 days, -I says ignore the Expires: header lines).
The crude but adequate way is to
find $SPOOLDIR/comp/mail/maps -type f -mtime +3 -exec rm -f {} \;
The crude method doesn't update your history files, which seldom matters.
Note that the nicer way will move history to ohistory, trashing any
previous ohistory. So if you need to use your ohistory files, either
run this expire and your regular one on separate days, or hack a shell
script to save ohistory in between.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various
# implements of destruction and went off to clean up the tty driver...heiby@falkor.UUCP (Ron Heiby) (03/22/88)
Rich Salz (rsalz@bbn.com) writes: > If you use UUHOSTS to unpack the maps directory, then you don't need > the maps in your spool directory at all. Get rid of them however > you like, I.e., Rich makes the same mistake here that I've seen others make when talking about getting rid of the map articles quickly. That mistake is that unless you are a LEAF node on Usenet, you have some responsibility to keep the map articles around long enough that they can get batched up for the sites you exchange news with. In many cases, this is no big deal, but if you are running a batching script that makes sure that it doesn't batch "too much" into the uucp spool directory for a particular site or if you are using ihave/sendme, then it may take a couple of days for the articles to get batched for the other site. If you've deleted them right after you received them, then they aren't given any (or much) chance to propagate. Let's be careful out there! -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "I believe in the Tooth Fairy." "I believe in Santa Claus." "I believe in the future of the Space Program."
kmcvay@oneb.wimsey.bc.ca (Ken McVay) (04/16/91)
Running /usr/lib/newsbin/expire/doexpire -v yields the following mail message: expire problems: kept, expired 205120 residual lines 27 links archived, junked, missing 000 Can someone translate this for me? Expire doesn't seem to be working correctly, but I don't know why... -- Support a Marine in the Gulf! Send your mail| ANY MARINE | via saudinet@oneb.wimsey.bc.ca, and use the | H&S Co.Maint.Plt. | address on the right to reach our 'adopted' | 2nd. LAI Btn.(DEPLOYED)| unit. (Email for instructions reaching others)|FPO NY NY 09502-0204 |
henry@zoo.toronto.edu (Henry Spencer) (04/17/91)
In article <1991Apr16.055706.338@oneb.wimsey.bc.ca> kmcvay@oneb.wimsey.bc.ca (Ken McVay) writes: >expire problems: > kept, expired >205120 residual lines >27 links archived, junked, missing >000 > >Can someone translate this for me? Expire doesn't seem to be working >correctly, but I don't know why... Looks like a stdio problem of some kind. Are you using our stdio speedups? If so, try rebuilding without them. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
john@news%jho@iex.com (John Ho) (06/01/91)
I found some old articles that should already been expired are still hanging around in the system and it all has a file size of zero. Any cure on why this is happening??? -- John Ho from Dallas, Texas, USA /--------------------------------------------/// john%jho@iex.com / Yes, I am technical but I don't talk funny./// uunet!iex!jho!john / Phone: (214)-907-9801 ///