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? |
|
@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.