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

sön 2014-01-26 klockan 13:59 +1300 skrev Amos Jeffries:

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

Please elaborate.

How do using a service name for these differ from having a squid.conf
set the name (possibly using the same service name as a macro
expansion)?

> Ditto for shared memory spaces.

Named shared memory spaces need consistent naming. Having a squid.conf
directive with a macro expansion using the service name is suitable
there as well.

> I am a little doubtful that we should be letting the PID file remain
> configurable, due to the same issue.

Please enlight me on what the issue really is here.

> We also seem to have a set of
> signalling issues due to that being reconfigured or created late in the
> startup process.

Then we have a broken process model somewhere.

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

Not at all, not for me at least. It's about being able to relocate the
Squid installation, i.e. for running it in a user home directory without
needing to rebuild Squid from source each time you change location.

> but in the context of signalling to one of multiple
> instances.

Signalling to a multi-instance Squid installation have not been a
problem before, you just need to remember to give the right squid.conf
when signalling so it knows the right pid filename.

> The service name was added to Windows apparently to solve the
> same problem there where PID file are not used.

And using it as one possible macro/variable expansion in squid.conf
makes great sense.

Having instance dependent stuff hardcoded in the binary and not being
able to set them in squid.conf is just wrong, even if derived somehow
magically from a service name by some means that someone thought was the
right.

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

Good.

Regards
Henrik
Received on Mon Jan 27 2014 - 07:07:48 MST