Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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.