Messages in this thread | | | Subject | Re: NR_OPEN vs OPEN_MAX vs RLIMIT_NOFILE, and a glibc bug? | From | Andreas Schwab <> | Date | 26 Mar 1999 13:42:37 +0100 |
| |
Olaf Titz <olaf@bigred.inka.de> writes:
|> > 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/
| |