Re: /bzr/squid3/trunk/ r12817: Log an ERROR instead of halting on unknown cache_dir types

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 16 May 2013 00:47:11 +1200

On 15/05/2013 4:26 a.m., Alex Rousskov wrote:
> On 05/14/2013 09:31 AM, Amos Jeffries wrote:
>> ------------------------------------------------------------
>> revno: 12817
>> Log an ERROR instead of halting on unknown cache_dir types
>>
>> Squid-3 can run fine without any configured cache_dir. This assists with
>> upgrade from older Squid-2 where COSS or NULL cache types may be present.
>> It also assists with backward compatibility for any future cache types
>> which may be added in future.
>> modified:
>> src/cache_cf.cc
>
> FWIW, I think Squid should refuse to start when misconfigured. Just
> because Squid "can work" without a directive, does not imply that the
> directive is not essential in a given setup. And problems with Squid not
> starting are usually much more visible to the admins than problems with
> Squid running misconfigured. Moreover, problems with Squid not starting
> are often less visible to users as a non-running Squid is going to be
> bypassed!
>
> Ignoring COSS cache_dirs does not assist with upgrade. The upgrade goal
> is to make Squid work better than it used to. Ignoring a cache_dir is
> unlikely to fulfill that goal unless Squid was misconfigured before the
> upgrade (i.e., was using a cache_dir that was not really needed).
>
> Ignoring "null" cache_dir is OK, but should be done differently and is
> probably not worth the extra code.

We agreed some time ago under the HotConf and again under the startup
speed discussions that it was acceptible to run without a cache loaded.
I just had not implemented this update yet. I did ensure this was a very
trivial change, tested it, and ensured that loud ERRORS are displayed
when the problem is detected.
This is only about the cache type and whether the module is built-in.
All other problems, for typos in paths, cache validity, and operational
parameters will still continue as before for all supported cache types.
Admin who have configured a known store type are required to have
configured it correctly, unknown/unsupported store types are what this
is about - the config fix for those is to *drop the cache_dir* or add
something completely different. This makes the first operation automatic
and loudly announces that the second step needs to be taken.

Amos
Received on Wed May 15 2013 - 12:47:24 MDT

This archive was generated by hypermail 2.2.0 : Wed May 15 2013 - 12:00:17 MDT