Re: [squid-users] squid smp fails -k reconfigure

From: Fernando Lozano <>
Date: Mon, 09 Jun 2014 11:38:38 -0300

Hi Alex,

First of all, thanks for the feedback.

>> 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.
Squid configuration examples and the wiki page about SMP tells to use
${process_number} to setup exclusive aufs caches for each worker.

See, for example,

Which was the inspiration for my setup.

If we should not use anything except rock store for SMP this should be
explicit in the docs/wiki/faq.

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

That's also news to me. I could not find anything on
stating reconfigure is problematic and should be avoided.

Just to make sure I understand correctly: I shoud restart squid, instead
of reconfiguring, when changing acls, and cope with the downtime?

>> 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.
So I'll try to hide the cache_dir aufs from the processes that doesn't
need them, as the default would be having no disk cache. I'll tell you
if this helped or not.

[]s, Fernando Lozano
Received on Mon Jun 09 2014 - 14:39:06 MDT

This archive was generated by hypermail 2.2.0 : Mon Jun 09 2014 - 12:00:04 MDT