https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293494
Bug ID: 293494
Summary: RLIMIT_NOFILE semantics seem to be incorrect
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
limits(1) describes the behavior of -n as adjusting the maximum number of open
file descriptors. I think this is the correct behavior. However, the kernel
seems to implement this as setting a limit on the maximum file descriptor that
is opened. This leads to a number of discrepancies:
- The limit can be set while there are too many open descriptors and more files
can continue to be opened as long as there are free slots below the given
maximum
- Even if there are fewer than the given number of descriptors open, dup
operations can fail if the "minimum fd" parameter to fcntl(F_DUPFD) is given.
I encountered this while running testcases for git. I had dozens of file
descriptors open from my desktop environment (probably shouldn't but whatever),
the test (t5324-split-commit-graph.sh) sets ulimit -n32 and does some
operations to make sure it works correctly under this kind of duress. It fails
in confusion over some combination of the above two points.
--
You are receiving this mail because:
You are the assignee for the bug.
