Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ?
Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).
On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote:
Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ?
Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).
This is not an Ubuntu limitation but rather of the (g)libc API implementation.
At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching.
http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2F...
Caveat: FD_... operations take longer if FD_SETSIZE is increased.
On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so.
Best is to internally replace select() with poll() on platforms that support it.
On 03/25/2011 06:26 AM, Dan Kegel wrote:
Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ?
Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).
So it turns out it's not a kernel config issue per se:
On 03/25/2011 06:05 PM, Tim Gardner wrote:
The initial hard limit value is not a CONFIG option, so the only way it can be changed is by carrying a patch in the kernel, something I would prefer not to do. This is the macro that initializes the hard limit:
include/linux/fs.h:#define INR_OPEN 1024 /* Initial setting for nfile rlimits */
What is the issue with having upstart set this limit early in the boot cycle? Won't all new processes inherit the modified limit?
If that's a good idea then we need to retarget the bug
-Scott Ritchie
-
Dan Kegel -
Paul Chitescu -
Scott Ritchie