|> > No, I don't have a patched kernel. Actually, I don't think there are over
|> > 1000 thousand file descriptors, just that there are over 1000 errors about
|> > them.
|> >
|> > It is like:
|> > ---------
|> > [some lines clipped.. if anyone wants a full log, email me]
|> > close(3) = 0
|> > munmap(0x400b3000, 4096) = 0
|> > getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
|> > close(1023) = -1 EBADF (Bad file descriptor)
|>
|> So your library, which obviously (s.b.) is libc6, implements
|> getdtablesize() by way of rlimit(RLIMIT_NOFILE), and both limits of
|> that resource are set to 1024. (Btw. on my system the hard limit is
|> 1024 and the soft limit 256, I'm too lazy to check where it was set
|> just now.)
|>
|> In order to do what it means, the library has to use the hard limit,
|> IMHO. But I'm not sure if this is exactly correct, however:
|> getdtablesize() should return the limit on fd numbers, and
|> RLIMIT_NOFIE specifies how many fds can be used, no matter what their
|> numbers. I.e. if I open 1023 fds, then close fds 0 to 1000, then lower
|> the _hard_ RLIMIT_NOFILE to 256, this should be OK because I have just
|> 23 open fds, but they are numbered 1001..1023 which is well above what
|> getdtablesize() subsequently returns.
Both getdtablesize and RLIMIT_NOFILE are only relevant for newly opened
descriptors. See f.ex. the manual page on SunOS4:
The call getdtablesize() returns the current value of the
soft limit component of the RLIMIT_NOFILE resource limit.
This resource limit governs the maximum value allowable as
the index of a newly created descriptor.
This means that in your szenario you would still be able to use all
descriptors, but dup2(1001,1000) would fail, and dup2(1001,255) would not.
-- Andreas Schwab "And now for something schwab@issan.cs.uni-dortmund.de completely different" schwab@gnu.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/