-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Fix rlimit setting of RLIM_NOFILE on OSX #14054
Conversation
This change fixes an issue with rlimit setting of RLIM_NOFILE. The problem is that the rlim_max that we get from getrlimit is too large and so setting the rlimit_cur to that value fails. The OSX man page for rlimit has a compat note about it, stating that the rlimit_cur needs to be limited to min(OPEN_MAX, rlim_max) if one wants to set it to rlim_max.
See https://github.com/dotnet/cli/issues/7247 for details on the issue that lead to discovery of this bug. |
Does this fix cases where you would need to manually use |
@dasMulli this fix ensures that the ulimit is set to the maximum possible value, so yes, it would fix such issues. |
Could this possibly be backported to 2.0.x given the number of ppl hitting this (see linked issues and possibly a few more) and it being hard to debug / fix if you don't know what you're looking for? |
@Petermarcu should we still get this to 2.0.2 or would you rather wait for 2.0.3 with this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@dasMulli it will be part of the next 2.0 update (2.0.2) |
This change fixes an issue with rlimit setting of RLIM_NOFILE. The problem
is that the rlim_max that we get from getrlimit is too large and so setting
the rlimit_cur to that value fails. The OSX man page for rlimit has a compat
note about it, stating that the rlimit_cur needs to be limited to
min(OPEN_MAX, rlim_max) if one wants to set it to rlim_max.
As an add-on change, I've also adds missing conversion from EMFILE errno
to ERROR_TOO_MANY_OPEN_FILES that has obscured the setrlimit issue since
the failure due to small limit was being reported as ERROR_GEN_FAILURE.