Ubuntu's next release and raising hard ulimit on ubuntu

[Dan Kegel]

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 ).

[Paul Chitescu]

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%2Fengi...

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.

[Scott Ritchie]

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