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

On 25/01/2014 8:50 p.m., Henrik Nordström wrote:
> fre 2014-01-24 klockan 14:27 -0700 skrev Alex Rousskov:
>> using the same Squid build (bug 3608). That bug report contains a
>> suggestion to make the currently ./configure-set IPC paths explicitly
>> configurable in squid.conf, but using service name side-effects also
>> works. I am not sure which approach offers the best overall solution.
>
> Everything should be set via squid.conf imho.

So how do we safely allow users to configure where the IPC sockets are
located on a per-worker basis while also allowing workers to communicate
over them to each other?

Ditto for shared memory spaces.

I am a little doubtful that we should be letting the PID file remain
configurable, due to the same issue. We also seem to have a set of
signalling issues due to that being reconfigured or created late in the
startup process. It seems to me the only reason that is being configured
at all is to get around this same (bug 3608) problem of instance
identification, but in the context of signalling to one of multiple
instances. The service name was added to Windows apparently to solve the
same problem there where PID file are not used. So making the
service-name feature generic deprecates at least that need for special
pid_filename directive.
 That said I'm not looking at removing it just yet until we can get some
good testing of service-name.

Overall the windows service-name seems to be a far better solution. The
service-name is available right from main() onwards in all processes to
which it is relevant. Admin just run Squid service with a given name and
the critical connections between processes for that service/instance can
all talk to each other without interfering with any other services, or
many config hoops to jump through.

FYI: The mention of other directives and uniqueness was not intended to
mean hard-coding that uniqueness. Just to highlight that it needed a
solution as well. Which turns out to probably be ${service_name} macro
suggested by Alex.

Amos
Received on Sun Jan 26 2014 - 00:59:19 MST