On 06/05/2014 10:54 AM, Fernando Lozano wrote:
> I find very strange that workers 6 and 5 try to get aufs cache stores.
> They are supposed to be the rock store disker and the coordinator! My
> squid.conf has:
>
> workers 4
> cache_dir aufs /cache/worker${process_number} 25000 16 256 min-size=31001 max-size=346030080
AUFS store is not SMP-aware. You should not be using it in SMP
configurations IMO.
> Is squid -k reconfigure working well for everyone else with SMP?
Reconfigure does not work well without SMP. It works even worse with
SMP. Log file rotation is an example of a problematic area specific to SMP.
> If kid5 is a disker, why does it setups up dns resolver and ldap auth
> helpers? It looks like disker and coordinator try to process all
> squid.conf directives, even when they are supposed not to do any
> network-related stuff.
There is no general rule that can tell a given Squid process which
configuration directives and modules are applicable to it and which can
be ignored. Many directives/modules depend on other directives and
./configure options, making such a determination even more difficult.
We are slowly adding the necessary exceptions/code to disable unneeded
features in SMP processes, but there is no project dedicated to that
activity (AFAIK). It will probably take a while to find everything that
should be disabled.
> Should I try to "hide" those directives from them?
In general, no. It is best to let your squid.conf reflect the entire
Squid instance configuration rather than sprinkle it with SMP
conditionals. Besides, many options have defaults so hiding them will
not produce the intended results. Squid will eventually learn to ignore
irrelevant settings on its own.
However, if hiding some directive works around a significant SMP
problem, hiding it may be better than waiting for others to fix the
actual problem.
> What means "not OK to rewrite swap log"? kid6 is the coordinator, it
> shoud not mess with cache dirs!
IIRC, there is a minor bug in Squid where it gets confused about the
state of swap log maintenance and emits the above warning. When the swap
maintenance code is moved to store modules where it belongs, this
problem will go away. IIRC, it is safe to ignore this warning for now.
Cheers,
Alex.
