I present the following truths:
- libc5 and glibc have hard-coded uses of FD_SETSIZE, in particular look
in res_send.c. Anything that uses FD_ZERO has a hard-coded use of
FD_SETSIZE.
- Applications such as Apache and ircds and whatnot hardcode FD_SETSIZE.
select() itself isn't the culprit, it's the macros such as FD_ZERO which
are the culprits.
- Various libraries (not naming any) do not even test the fd to see if
it's above their hard-coded FD_SETSIZE and so will result *in random stack
trashing behaviour when used with greater than 256 fds*
- 1024 isn't even safe, because older libc5 systems are not built for
anything above 256
I've asked before that the patch be modified to include a soft-limit of
256 and a hard-limit of whatever-huge-number-is-desired. My reasoning for
this is that it reduces the number of things that need to be recompiled.
For example see
<http://www.arctic.org/~dgaudet/patches/1024-descriptor.patch> for a patch
which protects programs by giving them a soft-limit of 256 and hard of
1024. (Yes I know it won't handle more than 1024 descriptors.)
Folks using any of these patches are foolish to not recompile at least
their libc.
Dean
On Wed, 25 Mar 1998, Dancer wrote:
> If you change the size of an fd_set in the kernel, you need to recompile
> anything that uses select(), otherwise you stand a good chance of
> blowing away the application's stack, IIRC.
>
> D
>
>
>
> Shane Anderson wrote:
> >
> > I'm looking for the *RIGHT* way to get more open files in 2.0.33.
> > I've downloaded Michael O'Reilly's patch, but it had problems with
> > portmapper (on RedHat 5.0 w/ all the latest updates) crapping
> > out--apparently due to bad file descriptors, which I think was due to
> > the dynamic allocation done in this patch. So, since then I've tried
> > to just change the #define's that I believe matter, namely:
> >
> > NR_OPEN in limits.h
> > OPEN_MAX in limits.h
> > __FD_SETSIZE in posix_types.h
> > __FD_SETSIZE in gnu/types.h
> >
> > And then if I put this in rc.local:
> >
> > echo 32768 > /proc/sys/kernel/inode-max
> > echo 8192 > /proc/sys/kernel/file-max
> >
> > Is this the Right Way? I'm still having trouble w/ portmapper (and
> > hence rpc.nfsd & rpc.mountd) At the moment I'm staring w/ a clean
> > 2.0.33 again and would like some real advice on # of open files
> > before I screw around too much more.
> >
> > Thanks!
> >
> > -= shane.anderson@infrasol.com ======== Infrared Solutions, Inc. =-
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
>
> --
> Did you read the documentation AND the FAQ?
> If not, I'll probably still answer your question, but my patience will
> be limited, and you take the risk of sarcasm and ridicule.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu