Re: [RFC] Squid process model and -z

On 11/06/2013 06:39 PM, Alex Rousskov wrote:
> On 11/06/2013 04:46 AM, Eliezer Croitoru wrote:
>> On 11/06/2013 12:00 AM, Alex Rousskov wrote:
>>> If we make squid-z a no-op, startup scripts that do not verify that
>>> squid-z worked will continue to work fine. However, there will be some
>>> upgrade pains for admins that use more complex startup scripts today. On
>>> the other hand, many of the admins are already experiencing upgrade
>>> pains because of how squid-z interacts with SMP now. It is difficult for
>>> me to say what kind of pain is preferable, but I think we should
>>> seriously [re]consider making squid-z a no-op as sketched above.
>
>
>> I was wondering why would the admin want to find and manage the
>> cache_dir by the startup script although it cannot determine anything
>> about this cache_dir (corruption etc...).
>
> AFAICT, there are no known use cases where the admin _wants_ to manage
> the cache_dir internals. All known use cases are the result of current
> Squid implementation _forcing_ the admin to manage the cache_dir
> internals by detecting and creating missing directories. As you have
> said, the startup script does not have enough information to do this
> management correctly in many cases.
In a case there are objects in the cache_dir that you dont want to erase
if there was a read\write error..
In the above case "squid -z" like operation is not wanted.

>
>
>> For now I found it very nice to have the -z option since sometimes there
>> are troubles that can be discovered by "squid -z" and not later on find
>> it in the cache.log.
>
> Can you detail this a bit please? Are you talking about running squid -z
> manually or from an unattented startup script? What kind of troubles do
> you discover by running "squid -z" that you cannot discover by running
> "squid".
Manually.
I have used glusterfs to store aufs cache_dir and when I wanted to
create the cache_dir I had a small problem:
squid -z resulted in a "flying" process that throws to STDOUT errors
about permissions of the creation of the cache_dir directories.
it's not about not discovering by squid but rather "squid -z" will leave
a daemon\process\fork open while the only way of knowing about it is the
cache.log while still throwing errors to the STDOUT.
I assume that reading these errors from cache.log should alert the admin
but I also will want to support the systemd journal in a way.
I will need to check this situation on a server like OpenSUSE that has
full systemd support.

>
>
>> What would be the alternative to get on STDOUT error messages on "squid
>> -z"?
>
> I am not sure I understand the question, but perhaps the answer is
> "squid -d1" or "tail -f cache.log"?
So for a systemd based system we will run squid with "squid -d1"?? to
log the needed information into the journal?
which ALL,1 should be logged this way if I am right about it.

>
>
>> systemd uses STDOUT\ERR and exit codes (standard way of doing things) to
>> log in the "journal" which is a nice thing.
>>
>> So would squid in SMP will\should use exit code of the startup process
>> to reflect the status of the cache_dir ??
>
> If cache_dir directory is missing and Squid is prohibited from creating
> it or ignoring the cache_dir, then Squid instance should exit with a
> non-zero exit code. This behavior should be the same for SMP and non-SMP
> cases.

OK

Thanks,
Eliezer
Received on Wed Nov 06 2013 - 17:33:13 MST