I just spent about an hour banging my head on a brick wall with the apparently well known “Unable to create selectable TCP socket” problem, which manifests itself most notably with failing imap_open() calls from PHP. It is related to fd_setsize and a frequent limit of 1024 open files (or at least selectable open files). It is quite well documented that it is some kind of bug/shortcoming in the c-client libraries that underlie a lot of email-related stuff, particularly the UW suite of tools like uw-imap, pine, alpine, etc. as well as the IMAP extension in PHP. I love being able to go Google for answers and find a ton of related content. It is really annoying though when people have been talking about this bug for years, since at least early 2007, with very very few workable solutions posted, or even workarounds.
So, I’m going to do my part: I found a workaround that I think might work very well for a lot of people who run into this problem. It’s biggest advantage is that it is very very easy to try, and has almost no downside, even if it doesn’t work for your particular situation. In my case, I found that Apache did indeed have a lot of files open, including log files for all my VirtualHosts, all the libraries that httpd depends on, files from sites that are hosted there (though it seems to open and close those just fine), and a large buildup of hundreds of entries for /tmp that were open and apparently never got closed properly. In my case, the server in question has an uptime of over 2 years, and while “apachectl restart” runs at least daily for log rotation, it seems that doesn’t really close unused file descriptors. The workaround I discovered was running “apachectl stop” followed by “apachectl start” which fixed the problem completely for me, at least for the next year or two I hope. From over 1600 open files, after restarting Apache fully that way, it only reopened about 325 files. And the imap_open() calls started succeeding as they should.
One last thought before I hop off my soapbox: when you find an answer to a problem, and that answer was hard to find or was not well documented, do your part to remedy that for the next guy or girl to hit that problem, and post your solution somewhere that Google will find it. It makes the internet a better place for all of us, and makes us all more productive. Who knows, maybe down the road you’ll run into the same problem again yourself, and not remember how to solve it until you find your own post from years before, and it will be your own time you’ll save. I fully recognize that a lot of what I accomplish each day is based on work done by others that I have found and emulated, as they say, standing on the shoulders of giants. Each contribution to the body of human knowledge lets us reach that much higher, so when you can, add your bit and as we all do that, it adds up.
Brian, 
