how does history file get too large?

bill davidsen davidsen at
Thu Jan 29 21:38:53 UTC 2004

In article <878yjrhiyz.fsf at>,
Russ Allbery  <rra at> wrote:
| Anne Wilson <anne at> writes:
| > If there was something that would just check the size of the file and
| > warn me if it's getting too big, then I could deal with it before it
| > becomes a problem.  news.daily?  expire?  Or, maybe that happened and I
| > missed it?  Just seems like there should be a better way to deal with
| > this problem besides the crash and burn approach.  (The only error
| > message was "ME source lost . Exiting")
| Yeah, I agree, we should have better error handling here.  I hope to
| eventually have a better history file format too; there's really no reason
| now for the history file to be textual, since it's actually a fixed-length
| field database for the most part and it's not like the entries are
| human-readable anyway.  That would reduce the size of the history file by
| about half.

And then we could spend years writing tools to get entries back to
readable format or new tools in something other than the usual
grep/perl/python solutions. I'm really not sure the gain justifies the
pain, most of us have tools which run against history. I know I do
operations against that format 4-5 times a month.

| > If I was to write such a script, could I just delete expired entries
| > from the history file, remake the indexes and overview, and have INN run
| > successfully?
| Yes, if the script does the following in this order:
|   Throttle innd.
|   Build a new history file (maybe as history.n).
|   Run makedbz on the new history file.
|   Replace the old history database with the new one.
|   Unthrottle innd.
| It's important for innd to be throttled during the whole period of time
| while you're changing the history file.
bill davidsen <davidsen at>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

More information about the inn-workers mailing list