Hi,
I'm testing squid squid-4.0.19-20170508-r15031 when I enable ssl-bump
in intercept mode, after couple of SSL requests squid crashes in
"Parser::BinaryTokenizer::want(unsigned long long, char const*) const
()" function.
OS: CentOS 5
OpenSSL: 1.0.1e-51
g++: 4.8.2-15
I have attached part of deb
On 10/18/16, Alex Rousskov wrote:
> On 10/17/2016 10:37 PM, Deniz Eren wrote:
>> On Mon, Oct 17, 2016 at 7:43 PM, Alex Rousskov wrote:
>>> On 10/17/2016 02:38 AM, Deniz Eren wrote:
>>>> 2016/10/17 11:22:37 kid1| assertion failed:
>>>> ../../src/ipc/Atomic
On Mon, Oct 17, 2016 at 7:43 PM, Alex Rousskov
wrote:
> On 10/17/2016 02:38 AM, Deniz Eren wrote:
>> 2016/10/17 11:22:37 kid1| assertion failed:
>> ../../src/ipc/AtomicWord.h:71: "Enabled()"
>
> Either your Squid does not support SMP (a build environment problem)
-g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables'
'PKG_CONFIG_PATH=/opt/squid/lib/pkgconfig:/opt/squid/share/pkgconfig'
--enable-ltdl-convenience
> I have also seen that yo
On Fri, Oct 14, 2016 at 1:50 AM, Alex Rousskov
wrote:
> On 10/13/2016 01:53 AM, Deniz Eren wrote:
>
>> I'm using squid's SMP functionality to distribute requests to many
>> squid instances and distribute workload to multiple processors.
>> However while run
Hi,
I'm using squid's SMP functionality to distribute requests to many
squid instances and distribute workload to multiple processors.
However while running squid's workers after a while worker processes
crash with the error below and coordinator does not start them again:
...
FATAL: Ipc::Mem::Seg
Little bump :)
I have posted bug report with steps to reproduce. The problem still
exists and I am curious whether anyone else is having the same
problem, too.
http://bugs.squid-cache.org/show_bug.cgi?id=4526
On Wed, May 25, 2016 at 1:18 PM, Deniz Eren wrote:
> When I listen to connecti
7.0.0.1.34693 > 127.0.0.1.icap: . ack 1 win 3186
[root@test ~]# netstat -tulnap|grep 34693
tcp 215688 0 127.0.0.1:34693 127.0.0.1:1344
CLOSE_WAIT 19740/(squid-1)
These CLOSE_WAIT connections do not timeout and stay until squid
process is killed.
2016-05-25 10:37 GMT+03:00 Deniz
2016-05-24 21:47 GMT+03:00 Amos Jeffries :
> On 25/05/2016 5:50 a.m., Deniz Eren wrote:
>> Hi,
>>
>> After upgrading to squid 3.5.16 I realized that squid started using
>> much of kernel's TCP memory.
>
> Upgrade from which version?
>
Upgrading from squ
Hi,
After upgrading to squid 3.5.16 I realized that squid started using
much of kernel's TCP memory.
When squid was running for a long time TCP memory usage is like below:
test@test:~$ cat /proc/net/sockstat
sockets: used *
TCP: inuse * orphan * tw * alloc * mem 20
UDP: inuse * mem *
UDPLITE:
> On 11/05/2016 8:19 p.m., Deniz Eren wrote:
>> Hi,
>>
>> In my system I am using netfilter marks to shape traffic(SNAT, QoS,
>> etc.) however when I redirect traffic to Squid using Tproxy I lose the
>> mark value(obviously).
>
> Not obvious at all. The
Hi,
In my system I am using netfilter marks to shape traffic(SNAT, QoS,
etc.) however when I redirect traffic to Squid using Tproxy I lose the
mark value(obviously). I saw configuration directive qos_flow but it's
only applicable for incoming connections( some website -> squid ->
client PC), what
established. Is there a way to force squid to check ACLs for
already established connections periodically?
Regards
Deniz Eren
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
13 matches
Mail list logo
