-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[linux] closefrom_shim: Add optimized fallback for platforms without closefrom or close_range #316
Conversation
Add an optimized fallback in closefrom_shim() for Linux, if the platform doesn't support closefrom or close_range. Iterate /proc/self/fd and close anything which is not that directory itself.
Interesting optimization, I hope to see some performance numbers, if possible. But I think it only applies on linux distributions with older Linux kernel versions, like 2.x? |
JFYI: The issue of high "ulimit -n" inside containers is described well here: https://github.com/moby/moby/issues/38814
Our issue was discovered inside a container based on SuSE SLES 15 SP5, running in Docker 24.x on RHEL 9.2/9.3. These are both current distributions, however I'll concede Docker on RHEL 9 is not well supported by either vendor. The RHEL9 system has kernel 5.14.0-284.18.1.el9_2.x86_64 and glibc-2.34-60.el9.x86_64.
Sure - see below. Without patch, inside SLES15 SP5 container on Docker 24 on RHEL9.3.
On SLES15 SP5, with "ulimit -n" = 1 million (2^20):
On SLES15 SP5, with "ulimit -n" = 1024 (2^10):
WITH patch, inside SLES15 SP5 container on Docker 24 on RHEL9.3.
As an aside, is it best to open a new "issue" for this discussion? |
Add an optimized fallback in closefrom_shim() for Linux, if the platform doesn't support closefrom or close_range.
Iterate /proc/self/fd and close anything which is not that directory itself.
This can save significant time if "ulimit -n" (max open files) is very high. For example, in some Docker containers the limit can be 2^30 (~ 1 billion), and lsof may take 10-30 minutes to start up.