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

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Fri, 24 Jan 2014 21:11:15 +0100

fre 2014-01-24 klockan 08:57 -0700 skrev Alex Rousskov:

> 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.

Do they really want the service name to have any other implications?

The only implicatin I might want to tie to the service name is the
default squid.conf name, but we do have command line option for
squid.conf name as well and think it is just more confusing than it adds
to automatically derive some squid.conf name from the service name. But
if Windows services only have the service name and no other parameters
available when run as a service then this may be needed. Was too long
since I dealt with Windows services to remember how they define what and
how to run.

> 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."

Do we have any?

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

Same here.

> 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.

Yes.

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

Right, that is an excellent idea. And if that also applies to include
then the first part mentioned above is solved nicely by having the main
squid.conf include service dependent parts which might in fact be the
entire squid.conf for that service if so desired.

Regards
Henrik
Received on Fri Jan 24 2014 - 20:11:23 MST

This archive was generated by hypermail 2.2.0 : Sat Jan 25 2014 - 12:00:13 MST