Chuck Kollars wrote:
... At the most the squid server would run for another day and then
stop running!!!!!! ... Please suggest some pointers to delete some
files under /var partition to create more space !!!!!! ...
Both your question and all the responses to it I've seen assume Squid is the cause of this problem, in other words that Squid is _using_ the missing disk space. Although this might be the case, it's not the only possibility. I wonder if something else is using the missing disk space, and Squid is just the victim?
Hes made a reasonable assumption on previous experience. A few weeks ago
when he came in it was Squid with an overly large cache configured and
dumping core files when the cache dir overloaded.
This time squids logs are getting extra large, so he needs to rotate
them as advised last time also.
But something else is also at fault this time around by the evidence given.
(I fear the actions you've taken in the past, deleting various files such as core.* and some Squid files, may have been just sticking bandaids on a broken leg. They may have bought you a few more months, but without ever addressing the real problem.)
When I have a partition that runs short of disk space, the first thing I find out is WHO. To do that, I work my way down the directory hierarchy to localize the problem to one particular folder, then look closely at all the files in that folder to see who created them and when. Even with its obvious holes, this simplistic procedure works pretty well in practice almost all the time. Here's an example:
cd /var # assume for this example /var is the problem partition
du -s * | sort -n
# bottommost line is the suspect, let's suppose for example it's 'log'
cd log
du -s * | sort -n # do it again
# bottommost line is the suspect, let's suppose for example it's 'cups'
cd cups
du -s * | sort -n # do it again
# stop, as no more sub-folders indicating we're at the bottom
ls -l *
# look at ownership and timestamps on files, imagine how they got this way
The max size of the Squid cache is specified in squid.conf. When it gets full, Squid will throw out the oldest files to make room for the new ones, so it will keep running all by itself. You should never have to explicitly delete any files out of the Squid cache.
You should make sure all the disk space that squid.conf says might be used is actually available (and continues to be available:-). To prevent the problem of something else sucking up all the disk space that was supposed to be for Squid, I put my Squid cache on a separate partition (not under /var at all) that doesn't contain anything else. (As an aside, using a separate partition also allows me to improve performance by easily using the 'noatime' mount parameter.)
I gave him all this same advice last time. Ho took it. the cache is in
/home and being happy. It's that other thing now cluttering up /var
still causing issues when it blocks squid log files.
So bakck to the du procedure again is best to find the second culprit.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
