Re: epoll behaviour after running out of descriptors

[Davide Libenzi <davidel@xmailserver.org>]

On Sat, 1 Nov 2008, Olaf van der Spek wrote:

> Hi,
> 
> I noticed some strange behaviour of epoll after running out of descriptors.
> I've registered a listen socket to epoll with edge triggering. On the
> client-side I use an app that simply keeps opening connections.
> When accept returns EMFILE, I call epoll_wait and accept and it
> returns with another EMFILE.
> This happens 10 times or so, after that epoll_wait no longer returns
> with the listen socket ready.
> I then close all file descriptors, but epoll_wait will still not return.
> So my question is, why does it 'only' happen 10 times and what is the
> expected behaviour?
> And how should an app handle this?
> 
> The example in the epoll man page doesn't seem to handle this.
> 
> An idea I had was for epoll_wait to only return with accept / EMFILE
> once. Then after a descriptor becomes available, epoll_wait would
> return again.
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502901
> 
> Hi,
> 
> I've written a web app that should be able to handle a lot of new
> connections per second (1000+). On multiple servers I've hit a bug.
> After running out of descriptors, then closing descriptors, epoll_wait
> doesn't return anymore for the listen socket.
> I've attached code to reproduce the issue. And an strace log. Even
> before closing the descriptors you see epoll_wait already stops returning.

A bug? For starters, epoll_wait does NOT create new files, so no EMFILE 
can come out from there.
You are saturating the port space, and your whole code logic is rather (at 
least) buggy. Try a `netstat -n -t | grep TIME_WAIT | wc -l`



- Davide