stever@tree.UUCP (Steve Rudek) (11/18/88)
(1) The news accounts keeps getting mail messages from root complaining that expire has encountered an 'Unparsable date "11/10/8<973@ccnysci.UUCP> GMT"'. How helpful. Somewhere, in one of my 3 jillion news articles located in one of several hundred newsgroups I've got a problem. The log files don't say anything more. What do I do now (please don't tell me to combine find and grep or I'm gonna cry)? (2) The rmgroup doesn't appear to accept "soc.all" as an argument. Is there an an easier way to delete numerous related newsgroups other than combining find with the rmgroup? FYI, "find" doesn't work in my news directories because the directories have been "linked" to other directories. (3) Why the hell are the news "log" files so huge? I started off keeping 7 days news. Then 5. Then 4. Last night I was seriously considering trimming down to *3* -- but then someone noticed that the miscellaneous log files (errlog, log, log.1, log.2, etc.) were occupying *megabytes* of space. I can accomodate several additional days of news for the price of those damned log files. What happens if I delete or trim them on a daily basis? Can these files be blocked or restricted in size via some news switch? I'm running bnews, yes. Don't know the version. As a more open question (perhaps one which belongs in another news group) what other files -- news related or otherwise -- have this sort of appetite for disk space and should be curtailed? User accounting files I know about. Thanks!
Makey@LOGICON.ARPA (Jeff Makey) (11/19/88)
In article <144@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >The news accounts keeps getting mail messages from root complaining that >expire has encountered an 'Unparsable date "11/10/8<973@ccnysci.UUCP> >GMT"'. Just grep for the message ID in your history file. It will tell you the newsgroup and the message number. >Why the hell are the news "log" files so huge? Because there's lots of news activity that gets logged. If you don't care at all about what's in the log file you could replace it with a link to /dev/null. On a daily basis I use the following commands to remove uninteresting lines from the log file: ----------------------------------------------------------------- #!/bin/sh fgrep -v "sent to downstream_host upstream_host Cancelling upstream_host linecount expected upstream_host received " log | grep -v " Can't cancel .* non-existent\$" | grep -v "upstream_host Ctl Msg .*: cancel" ----------------------------------------------------------------- >the miscellaneous log files (errlog, log, log.1, log.2, etc.) were >occupying *megabytes* of space. News doesn't care about what's in these files. All it asks is that errlog and log exist so it can append to them. You may trim them to your heart's content. Be warned, however, that some of the information in these files can be useful sometimes. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: nosc!logicon.arpa!Makey
bill@twwells.uucp (T. William Wells) (11/20/88)
In article <144@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
: (2)
: The rmgroup doesn't appear to accept "soc.all" as an argument. Is there an
: an easier way to delete numerous related newsgroups other than combining
: find with the rmgroup? FYI, "find" doesn't work in my news directories
: because the directories have been "linked" to other directories.
Grep through your active file for '^soc\.' and cut out the unnecessary
fields. Use the result of that as an argument to rmgroup.
: As a more open question (perhaps one which belongs in another news group)
: what other files -- news related or otherwise -- have this sort of appetite
: for disk space and should be curtailed? User accounting files I know
: about.
Part of my daily cleanup job summarizes disk usage. It has a set of
directories it does a `du' on, so that I can make sure none of them
gets out of hand. It then finds all files that have changed and are
not in any of those directories. This was very useful when I first set
up my system: it let me know which files got regularly changed, and
in particular, let me find where all the log files are.
Unfortunately, my system documentations was not terribly useful in
finding out where those files are. But I know now!
---
Bill
{uunet|novavax}!proxftl!twwells!bill