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

On 01/27/2014 03:44 PM, Amos Jeffries wrote:
> On 27/01/2014 8:18 a.m., Henrik Nordström wrote:
>> sön 2014-01-26 klockan 13:59 +1300 skrev Amos Jeffries:
>
>>
>>> 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.

My sense is that the Mem::Init() does not have to do with shared memory.

With a quick view I am seeing that shared memory initialized after
configuration file parsed, but the related objects and jobs are
created/scheduled before, with the hardcoded values.
This is makes changing ipc related paths with configuration parameter
mode difficult that expected (but not impossible)...

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

If the path of IPC sockets does not exist, squid does not reload or
shutdown and cachemgr does not respond. The system admin at the same
time is not able to understand where the problem exist, because there is
not any reference for these hardcoded files/paths inside
squid.conf.documented.

Also there are cases where the system admin wants to place these files
in other directory than the default. This is because of directory
permissions, or other reasons.
Just imagine the case you have to install to a customer a squid proxy,
on a system you do not have full root access and you are not able to
create directories where you want.

I am not saying that it must implemented right now, but I believe we
should consider it as a TODO.

We can use one configuration template file parameter similar to the
following:
 ipc_socket_template /var/run/squid/squid.ipc

The squid can use the above as template and append the kid number, or
process number or service name, or all of the above to generate ipc
socket files:
/var/run/squid/squid.ipc.coordinator
/var/run/squid/squid.ipc.kid1
/var/run/squid/squid.ipc.kid2
etc

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

Or
 D) use pid_filename as template and add the service_name if this is
defined:
    /var/run/squid.pid.servicename
This is because someone may need to run multiple squid instances for
which the pid files must located under the same directory.

However for multiple squid instances the system admin is already able to
use the pid_filename configuration parameter to define different pid
file for each instance. I am not seeing any need to change this one.

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

This is just my opinion.

Regards,
   Christos
Received on Tue Jan 28 2014 - 16:24:39 MST