lkml.org 
[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?
    Date
    From
    > 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.

    Olaf


    -
    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/

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