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

On 2014-01-30 06:55, Alex Rousskov wrote:
> On 01/29/2014 02:00 AM, Amos Jeffries wrote:
>
>> Lets assume for a minute or ten that we all agree with this design and
>> start implementing it ...
>>
>> A default Squid will need the following new directives:
>>
>> collapsed_forwarding_metadata_shm
>> collapsed_forwarding_queues_shm
>> collapsed_forwarding_readers_shm
> ...
>> * cache_dir needs to have;
>> * a new option added to explicitly configure the path to the
>> disker[...]
>> * a new option to link to the shared-memory segment for readers, and
>> * a new option to link to the shared-memory segment for writers.
>>
>>
>> Then we get to the UDS sockets...
>>
>> # assuming that we optimize a bit with a param for the process
>> number
>> # for a standard 8-core box with 2 cores for OS & coordinator.
>> workers 6
>> cordinator_process_uds_path /path/to/coordinator/uds/socket.ipc
>> kid_process_uds_path 1 /path/to/kid1/uds/socket.ipc
>> kid_process_uds_path 2 /path/to/kid2/uds/socket.ipc
>> kid_process_uds_path 3 /path/to/kid3/uds/wheeee.ipc
>> kid_process_uds_path 4 /path/to/kid4/uds/socket.ipc
>> kid_process_uds_path 5 /path/to/kid5/uds/socket.ipc
>> kid_process_uds_path 6 /path/to/kid6/uds/haha.ipc
>
> The kid executable (e.g., disker, coordinator, worker, etc.) path is
> already covered by the current Squid executable path.
>
> All others above (and more) can be covered with the following two
> options, with reasonable defaults (which may include a service name
> component), until we have a need for something more refined:
>
> shared_memory_dir
> uds_dir
>
> Not bad, IMO!

It is however the Y solution to an XYZ problem.
  .. unable to run two concurrent instances from same config file
  ... assume that moving paths will be enough
  .... ask for directive to configure paths
  Y: use new directive to change locations
  .. still unable to run two concurrent instances from same config file
  Z: use different setup/config for each proxy

When used via squid.conf directive, "same config" implies "same path
directive value". Ergo solution does not work to actually solve the core
problem of multi-instance collisions. But simply adds yet another option
on the nature of how/where the admin has to do to solve the real issue
(squid.conf uds_dir/shared_memory_dir vs squid.conf chroot vs. rebuild
with --prefix).

  -n service name does also adds yet another option, but does solve the Z
problem outstanding complaint of "same config file" without implying
solution Y (chroot / base_root setup).

Amos
Received on Wed Jan 29 2014 - 23:03:59 MST