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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
