It appears that the connect(2) function can yield a -1 (error) result and can set errno to EAGAIN/EWOULDBLOCK in some cases when trying to connect sockets that have previously been marked as non-blocking. Note however that the man page for connect(2) documents no such possibility. Given that the text associated with EAGAIN is "Resource temporarily unavailable" it is clear that some resource is being used up, but I have no idea which one or even how to find out which one. I *am* using quite a lot of sockets in the relevant program, but still, it is both annoying and troublesome to be getting an undocumented errno result from connect(2) and not even have it be clear which resource limitation is causing this. Fix: For the resource limitation: None known. For the documentation problem: Fix the ERRORS section of the connect(2) man page so that it includes EAGAIN and so that it specifies what resource limitations might cause this result. How-To-Repeat: Sorry, but I do not have any nice simple program which can demon- strate this problem at the moment... only a rather large application program. But if you need a small example program which triggers the problem (i.e. the undocumented EAGAIN errno result), let me know and I will try to cook one up.
A brief follow-up on my own PR. I dug around in the networking parts of the kernel and found that what was probably happening to cause EAGAIN errors to be issued in response to connect(2) call was a absence of available (auto assigned) port numbers for outgoing connections. /sbin/sysctl -a says (under default conditions): net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 This leaves less than 4000 available auto-assigned port number for outgoing connections. It appears that if those all get used up then connect(2) will start to yield -1 with errno set to EAGAIN. This should, of course, be documented in the ERRORS section of the connect(2) man page. Increasing the currently set value of net.inet.ip.portrange.last (via sysctl) seems to make the problem go away.
Responsible Changed From-To: freebsd-doc->wes@freebsd.org I'll shepherd this one, I've recently commited a fix to the code.
Responsible Changed From-To: wes@freebsd.org->wes s/wes@freebsd.org/wes/
Could this bug be closed? It looks like wes@ fixed it 5 years ago. Cheers, - Graham Percival
State Changed From-To: open->feedback Committed fix to man page, should be closed after verification.
State Changed From-To: feedback->closed Feedback timeout, close this (finally).