On 03/26/2011 11:21 AM, Steve Langasek wrote: > On Fri, Mar 25, 2011 at 07:05:00PM -0600, Tim Gardner wrote: >>> Perhaps this is an appropriate time to ask, since I've been trying to >>> ask for months now in mailing list/IRC but never apparently to the right >>> person... > >>> Can the kernel team please raise the hard limit for file descriptors >>> (but keep the soft limit)? > >>> https://bugs.launchpad.net/bugs/663090 > >>> I'm having real applications break from this, and the change shouldn't >>> affect any app that doesn't request it manually. > >> 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? > > upstart currently has no provisions for configuring system-wide default > ulimits. The kernel, on the other hand, does. If the defaults in the > kernel are wrong for the system, that should be remedied there (both > upstream and in Ubuntu). Architecturally, I can see no reason why upstart > should be setting this - if upstart is patched to set the ulimits, it will > only be as a workaround for wrong values in the kernel. >
I'm really hoping this doesn't devolve to a situation where no component wants to own a patch, and thus the problem goes unfixed for another year. -Scott Ritchie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel