Re: corrupt cache

I would suggest starting by looking through the cache/log file for all
occurances of 0000053A (this being the first one you mentioned was corrupt)
etc, and then also though your other logs for all the URLs referred to in
cache/log.
Hopefully you will see that something else was stored in this cache slot.

If it happened in only 6 days hopefully you still have the store.log and
access.log entries. My guess would be that something is being put into this
cache slot, but the log file isn't being updated properly. When the cache
re-starts after a crash it assumes that this file is what the log tells it it
is.

By the way our cache doesn't crash at all, I restart it occasionally because
we are still running 1.1.5 and it has memory and fd leaks, but ti happily runs
for months on end. (This is on a small Linux PC though, and not getting
hammered very much -- it is only used by a small number of people).

It might be worth trying to find out why your squid crashes, have you tried
examining the core dump to see what routine was in use at the time?

Looking in store.c it should be possible to make squid reject objects with the
wrong size. e.g. use the same logic as near the top of the function which
calls swapInError() if there was a problem reading the file. I don't know
this code that well though, so might break something.

 -- Jon
Received on Thu Jun 12 1997 - 07:52:05 MDT