Web traffic through our production ASL 5.011 with some 50 users at our training facility stopped flowing this week which is running as transparent HTTP proxy with Surfprotection enabled, e.g. Squid should implicitely be disabled.
However, while locking at the HTTP proxy live log on Webmin (which was still responding), I saw tons of error messages scrolling past about the disk partition of Squid being full!? The RRDTool graphs of the proxy's partition actually showed a steep increase of used disk space over two days, until the partition was full and the transparent proxy subsequently stopped to serve any pages.
I then disabled Surfprotection, after which I found that the Squid chache was still enabled. So I was able to use the Clear Cache button in order to try and clear the cache from Webmin.
Not even a minute later, the Web traffic through the proxy was flowing again, without having done a reboot nor a restart of the middleware. Also the disk usage of Squid's partition dropped back to "normal".
But this time, to be on the safe side, I manually disabled the cache before re-enabling Surfprotection. Because I did not do this past weekend - three days before the standstill occured - assuming that enabling Surfprotection will implicitely disable caching, in line with the open issue of caching being unable to coexist with Surfprotection.
However, the "crash" with the disk-full event of Squid's partition illustrates that Squid was apparently still caching pages somehow, even though Surfprotection was active. However, Squid failed to free any disk space which lead to a full partition, and a standstill of the proxy?
This smells like being a bug.
I now carefully watch Squid's partition. But so far its free space has not diminished anymore. So the bug workaround might indeed be to make sure that Squid is manually disabled before activating Surfprotection, at least when using transparent proxying.
Rolf
P.S. If excerpts from any logs might help to debug, please let me know.
This thread was automatically locked due to age.
