[lkml]   [1999]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectNR_OPEN vs OPEN_MAX vs RLIMIT_NOFILE, and a glibc bug?
> 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.

libc5 implements getdtablesize() to return the constant OPEN_MAX from
<linux/limits.h> which is 256 on a stock kernel. It looks to me that
the glibc way is "more right" but there is no point in setting the
resource limit higher than the kernel allows.

<linux/limits.h> from 2.2.4 sets OPEN_MAX to 256 and NR_OPEN to 1024,
which is the absolute limit for RLIMIT_NOFILE too. I'm a bit confused
about what the real limit is, does the above mean that the kernel is
prepared for 1024 fds per process but libc5 can only handle 256, or
what exactly does OPEN_MAX mean? Again CCd to linux-kernel.

> close(1022) = -1 EBADF (Bad file descriptor)
> [1019 lines removed]
> close(3) = -1 EBADF (Bad file descriptor)

But I was right in my observation that the many errors are indeed the
close-all loop. Someone suggested a more efficient method on
linux-kernel yesterday, I'll check that.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.086 / U:0.832 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site