[squid-users] SIGBUS attempting to use rock

[Antonio SJ Musumeci]

I'm currently unable to test fully due to my environment lacking 
CAP_IPC_LOCK. It does fail more gracefully saying it can't use mlock at all.

That said... the option is listed in relation to SMP and not referenced 
by rock docs. 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.

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.
>
>
> HTH,
>
> Alex.
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users