Re: [squid-users] not working tproxy in squid 3.2

On 1/04/2013 7:40 p.m., Oleg wrote:
> On Wed, Mar 20, 2013 at 11:35:21AM +0200, Eliezer Croitoru wrote:
>> On 3/19/2013 9:24 PM, Oleg wrote:
>>> On Tue, Mar 19, 2013 at 08:49:25PM +0200, Eliezer Croitoru wrote:
>>>> Hey Oleg,
>>>>
>>>> I want to understand couple things about the situation.
>>>> what is the problem? a memory leak?
>>> 1 problem - memory leak;
>>> 2 problem - tproxy doesn't work in squid 3.2.
>>>
>> I can think of a way you can configure squid to do cause them both.
> I think this is a bug in a software, if we can do memory leak and crash
> with bad config.

In your case with kernel limits of 800MB per-process this config will
guarantee it gets killed quickly. No memory leak required:

   cache_mem 900 MB

>
>>>> How do you see the memory leak? and where?
>>> I just start squid, start top and wait about a hour when squid grow from
>>> 40MB to 800MB and kernel kills it.

 From your config I see Squid is using its default 256 MB of cache_mem.
So you should expect to see at least 300MB of Squid RAM usage normally.

>
>>>> the more details you can give on the scenario and point with your
>>>> finger on the problem I will be happy to assist us finding the
>>>> culprit.
>>>>
>>>> What linux distro are you using?
>>> Debian 6 and also tried debian 7.
>> My opinion is that you dont need to test on 7 or do special tests
>> but it helped us to understand the nature of the problem.

The difference between 6 and 7 is the kernel version. Some Kernels are
known to have TPROXY bugs.
Also, the Debian kernels had non-working TPROXY for many releases after
the apparently identical upstream kernel version was working very well.
This affects Debian 6 for certain I'm not sure about 7.

>> Try to not use the filtering helper by using only defaults and tproxy.
>> and also try to use this script with trpoxy on port 3129 and
>> http_port 127.0.0.1:3128
>>
>> ##start of script
>> #!/bin/sh -x
>> echo "loading modules requierd for the tproxy"
>> modprobe ip_tables
>> modprobe xt_tcpudp
>> modprobe nf_tproxy_core
>> modprobe xt_mark
>> modprobe xt_MARK
> FATAL: Module xt_MARK not found.

I would guess this is related to the problem.

Theory: without MARK support in the kernel the TPROXY connections are
looping through Squid until the active connection state consumes 800MB
and gets killed.
Can you verify that at all?

Amos
Received on Mon Apr 01 2013 - 11:53:13 MDT