[squid-users] SIGBUS attempting to use rock
Antonio SJ Musumeci
trapexit at spawn.link
Thu Oct 17 21:07:58 UTC 2019
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  is a
> high-level description. Message  contains more low-level details and
> examples of ~60 second startup delays that locking may cause.
>  http://lists.squid-cache.org/pipermail/squid-dev/2016-March/005260.html
> Enhancing shared memory management (e.g., implementing ideas mentioned
> in the "As we gain more experience" paragraph of ) is welcomed.
> squid-users mailing list
> squid-users at lists.squid-cache.org
More information about the squid-users