On 11/06/2013 10:32 AM, Eliezer Croitoru wrote:
> 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.
I am not sure I understand: "squid-z operation" does not erase anything.
Folks that do not want Squid to create cache_dir structure
automatically, will need to add an option to squid.conf. That will be
one source of upgrade pains if we make "squid -z" do nothing.
>>> 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
Yes, it should. Moreover, manual cases like this are not really
important for this discussion because the admin can always manually
check what Squid is doing. The difficult case is when Squid runs under
some kind of automation such as a startup script.
> 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?
Sorry, I do not know where systemd can get process feedback. If it can
only get it from process standard output, then I suspect the answer
depends on the "needed information" definition: If ALL,0 already
contains all the needed information, then you need -d0. If you want
systemd to see ALL,1, then you need -d1.
I do not yet see how this "output capture" concern is related to the -z
discussion though.
Cheers,
Alex.
Received on Wed Nov 06 2013 - 18:02:25 MST
This archive was generated by hypermail 2.2.0 : Wed Nov 06 2013 - 12:00:15 MST