[squid-users] file descriptors leak

[André Janna]

  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
15 hours.
Right now lsof output is the same as 11 hours before:

squid     32490            proxy   12u    
IPv6            4065613      0t0        TCP
172.16.10.22:3126->192.168.93.113:55815 (CLOSE_WAIT)
squid     32490            proxy   14u    
IPv6            4097822      0t0        TCP
172.16.10.22:3126->192.168.90.207:52288 (ESTABLISHED)
...

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
ten?

Regards,
  André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151122/362ec520/attachment.html>