Bug 24125

Summary: connect(2) can yield EWOULDBLOCK/EAGAIN
Product: Documentation Reporter: Ronald F. Guilmette <rfg>
Component: Books & ArticlesAssignee: Wes Peters <wes>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Ronald F. Guilmette 2001-01-07 07:30:01 UTC 
	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.
Comment 1 Ronald F. Guilmette 2001-01-07 07:38:28 UTC 
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.
Comment 2 Wes Peters freebsd_committer freebsd_triage 2001-01-25 16:58:54 UTC 
Responsible Changed
From-To: freebsd-doc->wes@freebsd.org

I'll shepherd this one, I've recently commited a fix to the code.
Comment 3 Peter Wemm freebsd_committer freebsd_triage 2001-02-19 19:09:54 UTC 
Responsible Changed
From-To: wes@freebsd.org->wes

s/wes@freebsd.org/wes/
Comment 4 gpermus 2006-06-08 08:45:21 UTC 
Could this bug be closed?  It looks like wes@ fixed it 5 years ago.

Cheers,
- Graham Percival
Comment 5 Wes Peters freebsd_committer freebsd_triage 2006-08-16 03:56:57 UTC 
State Changed
From-To: open->feedback

Committed fix to man page, should be closed after verification.
Comment 6 Wes Peters freebsd_committer freebsd_triage 2006-09-24 00:03:45 UTC 
State Changed
From-To: feedback->closed

Feedback timeout, close this (finally).