[squid-users] FATAL: shm_open(/squid-ssl_session_cache.shm)

[Alex Rousskov]

On 08/28/2017 10:27 AM, Aaron Turner wrote:

> So I guess what I'd like to know is how squid handles a multi-layer
> cache config with ssl bumping?

If you are asking how to SSL bump requests in one Squid worker and then
satisfy those bumped requests in another Squid worker (and/or another
Squid instance), then the answer is that you cannot do that because
Squid does not support exporting decrypted bumped requests (without
encrypting them) from a Squid worker.


> For obvious performance reasons, I
> don't want to bump the same connection twice.  Much rather have the
> first layer bump the connection and have a memory cache.  If that
> cache is a miss, then hit the slower disk cache/outbound network
> connection.

Your desires require the currently missing Squid code to export bumped
requests _and_ they clash with the current Squid Project policy of
prohibiting the export of bumped requests.

If performance is important, consider using SMP-aware rock cache_dirs
instead of multiple Squid instances (including hacks that emulate
multiple Squid instances in a single Squid instance by abusing SMP macros).


HTH,

Alex.


> On Fri, Aug 25, 2017 at 3:13 PM, Alex Rousskov wrote:
>> On 08/25/2017 11:21 AM, Aaron Turner wrote:
>>> FATAL: Ipc::Mem::Segment::open failed to
>>> shm_open(/squid-ssl_session_cache.shm): (2) No such file or directory
>>
>>> I've verified that /dev/shm is mounted and based on the list of files
>>> in there, clearly squid is able to create files there, so it's not a
>>> Linux/shm config issue.
>>
>> Yes, moreover, this is not a segment creation failure. This is a failure
>> to open a segment that should exist but is missing. That segment should
>> have been created by the master process, but since your config (ab)uses
>> SMP macros, I am guessing that depending on the configuration details,
>> the master process may not know that it needs to create that segment.
>>
>> For the record, the same error happens in older Squids (including v3.5)
>> when there are two concurrent Squid instances running. However, I
>> speculate that you are suffering from a misconfiguration, not broken PID
>> file management here.
>>
>>
>>> So here's the funny thing... this worked fine until I enabled
>>> ssl-bumping on the backends (I was debugging some problems and on a
>>> whim I tried enabling it).  That didn't solve my problem and so I
>>> disabled ssl bumping on the backends.  And that's when this SHM error
>>> started happening with my frontend.   Re-enabling ssl-bump on the
>>> backends fixes the SHM error, but I don't think that would be a
>>> correct config?
>>
>> This is one of the reasons folks should not abuse SMP Squid for
>> implementing CARP clusters IMHO -- the config on that wiki page is
>> conceptually wrong, even though it may work in some cases.
>>
>> SMP macros are useful for simple, localized hacks like splitting
>> cache.log into worker-specific files or adding worker ID to access.log
>> entries. However, the more process-specific changes you introduce, the
>> higher are the changes that Squid will get confused.
>>
>> The overall principle is that all Squid processes should see the same
>> configuration. YMMV, but the number of places where SMP Squid relies on
>> that principle keeps growing...
>>
>> Alex.