Date: Sat, 28 Feb 2026 05:57:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293494] RLIMIT_NOFILE semantics seem to be incorrect Message-ID: <bug-293494-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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: bugs@FreeBSD.org Reporter: audrey@rhelmot.io 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293494-227>