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

On 27/01/2014 8:18 a.m., Henrik Nordström wrote:
> 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)?

squid.conf lines effects differ based on all the variability of process
macros and if..endif conditionals.

Service name is static for the instance.

Meaning we can use service name much more definitively as a macro for
the configurable options that need to be unique, and as a separator for
the non-configurable details as well.

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

Delaying Mem::Init() until after the config parsing does not appear to
be an option. There are a handful of components whose squid.conf parsing
depends on it being done beforehand.

Using service name places the control in users hands without having to
redesign the squid.conf parsing and initialization in a big way right now.

I also think that it provides sufficient control over all the relevant
pieces

As it is I have spent the day fighting the code against memory related
globals involvement with service_name. Since it is not initialized until
main(), which for some components is very late already. I think we can
delay them a bit until Mem::Init() time, but later will cause problems
with the config parsing itself.

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

Same as with the UDS sockets. Having it squid.conf configurable allows
for one instance of SMP Squid to have multiple *.pid files with any
permutation of PID file to SMP shared resources.
Why do we only have one .pid file with SMP-aware Squid and not one for
each process started?

 pid_filename /var/run/squid/kid${process_number}.pid

The complexity it creates is really not necessary IMO.

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

Yup. squid -k and system processes depending on having *the* PID file
pointing at a process that can reach the coordinator. Versus the PID
file pointing at a process isolated from the others due to per-worker
squid.conf settings.

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

Being able to relocate the running state directory from squid.conf seems
to me the scope of chroot directive rather than pid_filename.

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

For tools which do not parse squid.conf properly or understand our SMP
config macros that is a problem.

For Squid where the PID file depends on a macro (like above) it is also
a problem. I was unable to use squid -k to shutdown or restart a Squid
with two workers and the above mentioned config line, or if pid_filename
was wrapped in an if..endif conditional.

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

Macro name is done in trunk now.

What I am thinking for .pid is one of:

A) replace the @DEFAULT_PID_FILE@ with --prefix based path and
${service_name} macro for generating default filename.

B) deprecate pid_filename in favour of directive pidfile_path and make
the name be ${pidfile_path}/${service_name}.pid

C) remove pid_filename directive and use chroot directive and -n command
line instead.

(c) is very tempting, since we can then reliably assume the FHS
structure (underneath chroot directory) with just configurable filename
for pid.

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

Hardcoding instance specific items *is the status quo*.

Amos
Received on Mon Jan 27 2014 - 13:44:58 MST