[squid-users] SIGBUS attempting to use rock

[Alex Rousskov]

On 10/17/19 5:07 PM, Antonio SJ Musumeci wrote:

> the option is listed in relation to SMP and not referenced by rock docs.

The second paragraph in cache_dir rock directive documentation implies
SMP -- it talks about various processes that rock uses to avoid locking
(if it can). SMP usage is the primary rock scalability feature. There is
more info at https://wiki.squid-cache.org/Features/RockStore (and
https://wiki.squid-cache.org/Features/LargeRockStore).


> Also it should be possible to check /dev/shm's free space
> and compare that against the file size needed. Clearly it knows based on
> the requested storage and slot sizes. Even a guess with a warning rather
> than leaving it to fail otherwise silently with a SIGBUS.

Unfortunately, a simple implementation may produce a lot of false
warnings in some environments while a quality implementation may not be
as easy as you think: Accessing free space info may require special
permissions and correctly accounting for the existing shared memory
segments in that partition would be tricky (they can be leftovers from
the previous Squid run that will be overwritten or something completely
unrelated to Squid). Even finding the right partition name in a portable
way may be tricky!

IMHO, the future development directions outlined when adding
shared_memory_locking are more promising in general, but I would be
happy to learn that there are even better options.


Cheers,

Alex.


> On 10/17/2019 2:53 PM, Alex Rousskov wrote:
>> On 10/17/19 12:28 PM, Antonio SJ Musumeci wrote:
>>
>>> After a lot of tinkering and turning on full debug I realized the reason
>>> rock was failing for me in my container was due to the small default SHM
>>> size allocated by Docker. Increasing the SHM size with `--shm-size`
>>> fixed the issue.
>>>
>>> It'd be significantly more helpful if the Squid reported precisely what
>>> the issue and exited gracefully rather than SIGBUS'ing.

>> Does enabling shared_memory_locking in squid.conf trigger the behavior
>> you want?
>>
>> If yes, then you may be wondering why this is not the default setting.
>> The answer is in the following two squid-dev messages. Message [1] is a
>> high-level description. Message [2] contains more low-level details and
>> examples of ~60 second startup delays that locking may cause.
>>
>> [1]
>> http://lists.squid-cache.org/pipermail/squid-dev/2016-March/005260.html
>>
>> [2]
>> http://lists.squid-cache.org/pipermail/squid-dev/2015-December/004112.html
>>
>>
>> Enhancing shared memory management (e.g., implementing ideas mentioned
>> in the "As we gain more experience" paragraph of [1]) is welcomed.