[squid-users] [PATCH] Squid 3.5.19 SMP under OpenBSD - setsockopt for UDS

[Amos Jeffries]

On 27/06/2016 9:16 p.m., Silamael wrote:
> Hi,
> 
> I'm playing around with the SMP feature on OpenBSD 5.9 and noticed that
> Squid does not run due to hard coded limits for the receive and send
> buffer sizes of Unix Domain Sockets. In contrary to other OSes these
> limits cannot be adjusted by a sysctl.

Is that a new regression in 5.9?
Can you provide a reference please?

We have had Squid working just fine with SMP on OpenBSD before.


> The attached patch adds some setsockopt() calls to comm.cc which sets
> the buffer sizes to 256kb.

Please submit patchs to the squid-dev mailing list.

Please also include an example of the errors that are visible to users
with your squid-dev submission so we can refer people complaining about
specific error messages to the appropriate fix.

And detail of where the 2K/4K limit you mention is located. So we can
verify if you are looking at the right limitation and what else it affects.
 AFAIK, the UDS limitations are about the size of objects which are used
over UDS sockets. Reading 256KB into a 4KB object does not have pretty
results. Likewise a blocking queue of up to 64 time-critical SMP actions
awaiting the first one getting its synchronous UDS response does not
have good side effects.

We no longer accept #ifdef construction in squid coding guidelines. Use
#if instead. If you can please also identify what other *BSD are needing
this and add them to the #if condition.
 Though if this is accepted the change may be relevant to all OS and not
needing a wrapper at all.


> 
> PS: Also i noticed that if squid is called with -z for creating the
> cache directories, that ${process_number} macro is not expanded but
> always set to 0. squid -z only creates one cache dir although in the
> configuration
> cache_dir ufs /var/squid/cache/cache-foo-${process_number} 700 8 16
> is set.

That sounds more like the behaviour of "-N -z".

Just "-z" spawns the SMP workers and each worker generates its own cache
directories before exiting. That is needed in Squid-3 since only the
worker knows what its cache_dir expansions are.

Note that the master -z process may exit far faster than any of the
workers during a SMP aware -z execution since it has nothing to do. Your
script may not be waiting long enough for the cache dir creation to
happen in workers. YMMV, but I give -z at least 10 seconds to complete.

If a worker is still running when you start the normal Squid process
then UDS socket errors are almost guaranteed. Timing races mean it may
not happen reliably, but usually does.

Squid-4 has the --foreground command line option to avoid these problems.

Amos