Bug 6685 - Connections leaking in FastCgi when hosted on TCP socket
Summary: Connections leaking in FastCgi when hosted on TCP socket
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Web ()
Version: master
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-08-24 18:25 UTC by pgentoo
Modified: 2012-08-25 06:34 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 6685 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description pgentoo 2012-08-24 18:25:20 UTC
Similar to https://bugzilla.xamarin.com/show_bug.cgi?id=3765, however 3765 only seems to resolve the issue if using a UNIX socket backed fastcgi process.  If using TCP, the problem remains.

I was able to repro this with creating a single page HelloWorld.aspx application, and holding down F5 in the browser to continuously refresh it.  

Running "lsof|grep mono|grep identify|wc -l", you'll see that the handle count will grow for broken socket connections like the following:

mono      28944 28958      nginx  338u     sock                0,6        0t0   17471206 can't identify protocol
mono      28944 28958      nginx  339u     sock                0,6        0t0   17473562 can't identify protocol
mono      28944 28958      nginx  340u     sock                0,6        0t0   17480635 can't identify protocol
mono      28944 28958      nginx  341u     sock                0,6        0t0   17473629 can't identify protocol
mono      28944 28958      nginx  342u     sock                0,6        0t0   17473639 can't identify protocol
mono      28944 28958      nginx  343u     sock                0,6        0t0   17473346 can't identify protocol
mono      28944 28958      nginx  344u     sock                0,6        0t0   17489879 can't identify protocol

Without 3765 (using packaged version of XSP 2.10) whether on a TCP or UNIX socket I experience this issue.  After moving to latest XSP trunk, and TCP socket issue remained.  Switching to unix socket resolved the issue, so it seems that maybe there is some parallel/similar code that needs to be handled for unix socket connection issues?

Result of this bug is the same as 3765, handles being exhausted and service failures occurring due to too many open files and/or memory usage/swapping.