[squid-users] file descriptors leak
andre61 at brazcubas.br
Sun Nov 22 14:01:21 UTC 2015
Citando Amos Jeffries <squid3 at treenet.co.nz>:
> CONNECT requests with tunnels can be particularly long lived, mobiles
> and their applications stay active for weeks on end with few outward
> signs of what is happening inside the encrypted tunnel. The only way to
> be sure the connection is finished with is when one of the client or
> server remote endpoints closes it.
> * The port 55815 connection _was_ closed sometimes within 15 mintes of
> the lsof being run.
> * The port 52288 connection is still being used.
> Given the timespan between those messages and the lsof, it is also
> possible they were closed and reopened in between. If you have a lot of
> ports in active use, then re-use of closed ones becomes more likely.
> Though I suspect it is just persistence doing what it is designed to do.
> You will need a more detailed trace of the entire time period to know.
11 more hours have passed since my last "lsof" and cause it's Sunday I'm
sure that no device have been connected to 192.168.x.x network at least for
Right now lsof output is the same as 11 hours before:
squid 32490 proxy 12u
IPv6 4065613 0t0 TCP
squid 32490 proxy 14u
IPv6 4097822 0t0 TCP
Squid is still using file descriptors 12 and 14 (and a lot of others) for
the same connections as yesterday, although the mobile devices it was
connected to have not been online in our network for at least 15 hours.
Is it by design?
Raising file descriptors limit is the only solution?
The maximum number of file descriptors in my installation is set to 65535.
Is there any drawback to increasing this number let's say by a factor of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squid-users