Re: [RFC] Squid process model and service name impact

On 01/23/2014 09:00 PM, Amos Jeffries wrote:

> The opening up of -n is now done in trunk. Anything which needs to be
> unique for the instance/service should begin to make use of the global
> char* service_name as part of its uniqueness.

The above scope definition would apply to things like the default
squid.conf and logs location. That is doable, but tricky, and I suspect
that is not exactly what those admins actually want. If we implement
using that scope, the next complaint we might get is that they now have
to duplicate mime.conf and such.

Please note that since Windows admins want a service name even if they
do not run multiple single-build instances on the same box, setting that
service name should not suddenly make their life more difficult by
altering squid.conf location and such. You can make exceptions for
"default" service name such as "squid", but it may get pretty messy
pretty quickly.

As an alternative, you can restrict the scope to something like this:

"All --prefix dependent names not already configurable via squid.conf or
command line that may lead to a conflict between multiple concurrent
instances of a single Squid build."

That alternative scope definition will leave squid.conf and PID file
locations alone (at the expense of admins having to configure those
aspects manually).

> PID file is the trickiest piece. I am thinking we will need to convert
> the squid.conf string directive from file+path into just path, and
> generate the filename from the service_name instead of allowing manual
> configuration of it.

I am thinking we should not touch anything that is already configurable
via squid.conf or command line options.

pid_filename is similar to http_port, cache_dir, and probably other
options. IMO, those few folks that want to run multiple instances of the
same Squid build should be willing to pay the price of carefully
configuring each instance.

BTW, you may want to add a ${service_name} macro support to squid.conf
parser to make multi-service configuration easier.

Cheers,

Alex.
Received on Fri Jan 24 2014 - 15:58:16 MST