Just a note: This is actually not all that is needed to run in smp mode. ;( 

You need this fix, but then if you are using a cache_dir you have to:

* Make sure cache_dir is defined _after_ workers N in the config. 

* Use smp macros in the squid.conf to define a seperate cache_dir for each worker. 

* Manually run: squid -z -F -f /etc/squid/squid.conf to create the cache dirs before starting squid. The current systemd unit files runs this with -N (no daemon) and in that mode squid doesn't expand the macros, so it would only ever create the first cache dir. ;( 

ie: 

workers 2
if ${process_number} = 3
       # nothing
else
       cache_dir ufs /var/spool/squid/${process_number} 100 16 256
endif

Perhaps this can just be commented on in the squid.conf if smp isn't default?

Kevin, I agree having your sample config on the package squid.conf would be nice. Probably I didn't had problems creating the cache_dirs because I tested using squid-cache.org provided rpms, than just checked if the changes I need were or not on the Fedora / RHEL packages. I have not actually tried Fedora the packages.

(In reply to Kevin Fenzi from comment #5)
> Just a note: This is actually not all that is needed to run in smp mode. ;( 
> 
> You need this fix, but then if you are using a cache_dir you have to:
> 
> * Make sure cache_dir is defined _after_ workers N in the config. 
> 
> * Use smp macros in the squid.conf to define a seperate cache_dir for each
> worker. 
> 
> * Manually run: squid -z -F -f /etc/squid/squid.conf to create the cache
> dirs before starting squid. The current systemd unit files runs this with -N
> (no daemon) and in that mode squid doesn't expand the macros, so it would
> only ever create the first cache dir. ;( 
> 
> ie: 
> 
> workers 2
> if ${process_number} = 3
>        # nothing
> else
>        cache_dir ufs /var/spool/squid/${process_number} 100 16 256
> endif
> 
> Perhaps this can just be commented on in the squid.conf if smp isn't default?

Hi Kevin,

If I understand to your comment you correctly, you are just advising, how should system administrator configure the Squid proxy.  I can add some commented commands to squid.conf.default.

But the main problem of this bug report was, that squid was not able to handle any requests, when "workers N" option was specified in squid.conf, which was solved by adding /var/run/squid directory. I tried to reproduce this issue on my VM, and after adding this directory, issue was fixed (squid could handle requests).

(In reply to Luboš Uhliarik from comment #8)
> Hi Kevin,
> 
> If I understand to your comment you correctly, you are just advising, how
> should system administrator configure the Squid proxy.  I can add some
> commented commands to squid.conf.default.

Yeah. 

> But the main problem of this bug report was, that squid was not able to
> handle any requests, when "workers N" option was specified in squid.conf,
> which was solved by adding /var/run/squid directory. I tried to reproduce
> this issue on my VM, and after adding this directory, issue was fixed (squid
> could handle requests).

Yes, but if you then add a simple 'cache_dir' it will break and do odd things (as all the workers share a cache_dir which shouldn't be the case). I just wanted to suggest adding some comments around that or doc note or something. Perhaps a smp howto in the portal? up to you, I just wanted to bring it up.

(In reply to Kevin Fenzi from comment #9)
> (In reply to Luboš Uhliarik from comment #8)
> > Hi Kevin,
> > 
> > If I understand to your comment you correctly, you are just advising, how
> > should system administrator configure the Squid proxy.  I can add some
> > commented commands to squid.conf.default.
> 
> Yeah. 
> 
> > But the main problem of this bug report was, that squid was not able to
> > handle any requests, when "workers N" option was specified in squid.conf,
> > which was solved by adding /var/run/squid directory. I tried to reproduce
> > this issue on my VM, and after adding this directory, issue was fixed (squid
> > could handle requests).
> 
> Yes, but if you then add a simple 'cache_dir' it will break and do odd
> things (as all the workers share a cache_dir which shouldn't be the case). I
> just wanted to suggest adding some comments around that or doc note or
> something. Perhaps a smp howto in the portal? up to you, I just wanted to
> bring it up.

I agree too, it is good to have it documented, so I will comment this problem and try to write some article about it.

But I'm curious, how it can break and do odd things. My testing configuration now looks like:

----------- squid.conf ----------
# 
# Recommended minimum configuration:
#
cache_dir ufs /var/cache/squid 500 16 256

...
...
...

workers 2
------------

and I'm not experiencing any problem with it. Can you please tell me, what kind of problem is happening to you, when more workers are using same cache dir? I just wanted to reproduce it for myself.

I found the same thing, you are talking about in Squid documentation

http://www.squid-cache.org/Doc/config/cache_dir/

"In SMP configurations, cache_dir must not precede the workers option and should use configuration macros or conditionals to give each worker interested in disk caching a dedicated cache directory."

Squid docs state that you cannot share a cachedir between workers, that's why you need the macros. As most multithreaded programming issues, you probably won't have a problems with small-scale tests.

http://wiki.squid-cache.org/Features/SmpScale

"Currently, Squid workers do not share and do not synchronize other resources and services, including (but not limited to):

    memory object cache (in some environments),
    disk object cache (except for Rock Store), 
..."

PS: In Linux the memory cache is shared, that that's why you need /var/run/squid, so it can create the shared memory files.

Yeah, in my testing here (with 8 workers) if you share cache, sometimes workers die, sometimes it serves corrupt files, sometimes disk usage isn't cleared up. It's not an immediate failure, but it does fail.

Changing bug name, because /var/run/squid dirrectory need to be created while squid is starting. Having this dirrectory in rpm doesn't help, because in default RHEL-7 system this location is on /run, which is temporary filesystem.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2378.html