The developers of Smoothwall Express v3.1 have been trying to address this issue for a few days now. We have had users complaining of this same issue with Squid 3.5.5 and 3.5.6. It didn't seem to happen with prior versions. We (or at least our lead developer Neal Murphy) thinks it is related to shutting down Squid with a single SIGTERM followed by a SIGKILL a few seconds later (or just using squid -k shutdown) is causing squid to close and exit before the swap.state file is written and saved. This causes a corrupted swap.state file to exist when squid is restarted. When Squid crashes, rebuilding the swap.state anew seems to fix the problem and Squid can restart.
So, to fix the crashing problem, for us at least, seems to involve redesigning the shutdown and restarting of squid. Neal has come up with a process and scripts that seem to fix the issue, at least for low loads on squid that typically are what our users use. Neal has run some tests on higher loads and it seems to work as well for those environments as well, but we are continuing to test. Here is a link to the discussion in the Smoothwall community forums if anyone is interested.http://community.smoothwall.org/forum/viewtopic.php?p=340353#p340353
On Sun, Jul 26, 2015 at 3:53 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 26/07/2015 5:09 p.m., The_Spider wrote:
> To anyone willing to assist.
>
> My Squid continues to crash for some un-known reason only giving
> 'FATAL: Received Segment Violation...dying.' I have attached a copy of
> the cache log with the crash occurring and output debugging.
>
> Aparently I'm not the first to experience this, but I have yet to find
> any documentation on how to resolve this issue. This is not unique to
> one single machine, it happens on a few different boxes with similar
> configuration, I have not been able to identify what configuration
> parameter has been causing the issue.
>
Please follow the steps for obtaining a traceback as outlined at
<http://wiki.squid-cache.org/SquidFaq/BugReporting#crashes_and_core_dumps>
For SEGFAULT errors that is the only easy way to identify what the
problem is. Trial-and-error can take a very, very long time.
As for the config. You certainly have a thing for regex. Most if not all
of the dstdom_regex patterns would be far better written as dstdomain ACLs.
Although note that neither dstdomain nor dstdom_regex work properly in
the ssl_bump directive lines. Use "ssl::server_name" ACL for those checks.
> I will attempt to provide any information possible to help resolve
> this issue. Hopefully this is a good start.
>
> cache.log = http://filebin.ca/29vS8jkEfskt/cache.log
>
> squid -v:
> Squid Cache: Version 3.5.6-20150725-r13869
> Service Name: squid
> configure options: '--prefix=/usr' '--exec-prefix=/usr'
> '--includedir=/usr/include' '--datadir=/usr/share'
> '--libdir=/usr/lib64' '--libexecdir=/usr/lib64/squid'
> '--localstatedir=/var' '--sysconfdir=/etc/squid'
> '--sharedstatedir=/var/lib' '--with-logdir=/var/log/squid'
> '--with-pidfile=/var/run/squid.pid' '--with-default-user=squid'
> '--enable-silent-rules' '--enable-dependency-tracking'
> '--with-openssl' '--enable-icmp' '--enable-delay-pools'
> '--enable-useragent-log'
--enable-useragent-log no longer exists.
> '--enable-esi'
> '--enable-follow-x-forwarded-for' '--enable-auth'
> --enable-ltdl-convenience
>
> cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
>
Amos
_______________________________________________
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
